Date: Sun, 1 Apr 2007 18:28:28 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: Jail services. Message-ID: <20070401162828.GD25661@garage.freebsd.pl>
next in thread | raw e-mail | index | archive | help
--Dzs2zDY0zgkG72+7 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. The patch below implements something what I called 'jail services'. We discussed such mechanism on AsiaBSDCon07 developers summit, some slides are at: http://wiki.freebsd.org/AsiaBSDCon_2007_DevSummit?action=3DAttachFile&do= =3Dget&target=3Djail_services.pdf The patch is at: http://people.freebsd.org/~pjd/patches/jail_services.patch The patch contains actually 3 things, sorry about that, but those are somehow related: 1. Jail services implementation. 2. Implementation of security.jail.jailid and security.jail.mount_allowed sysctls. 3. Addition of VFCF_JAIL file system driver flag. Description of 1. Jail services provide easy to use KPI to attach data to in-kernel jail's structure. I'd explain it based on ZFS. If we want to attach the given file system tree to the given jail, we attach list of file systems to the jail structure, which we can then use for security checks. ZFS registers itself by calling: struct prison_service * prison_service_register(const char *name, prison_create_t create, prison_destroy_t destroy); 'create' is a callback function, which is called for every created jail and for all jails that already exist. 'destroy' is a callback function, which is called if jail is removed or when we deregister our service. The prison_service_register() dynamically allocates a slot in jail's structure for our use. We can store a pointer in this slot with prison_service_data_set() function on jail creation (from within create() callback). We can then get this pointer with prison_service_data_get() function or remove it with prison_service_data_del() function when destroy() is called. There are no preallocated slots, so it takes no more memory than we have jail services. No jail services - no addtional memory will be used. If jail service deregisters itself, its slot is only freed when it was the last one. If it was in the middle of slots table it will be used by another jail service. I changed prison_mtx to shared-exclusive lock, because we may want to allocate memory while holding it. I also changed the code to use shared lock when it doesn't modify jail's list. The KPI is more precisely documented in the code (kern_jail.c). Description of 2 and 3. The security.jail.jailid sysctl return jail's ID of the jail we are in and 0 if we are not inside a jail. With this sysctl in-place we can remove security.jail.jailed. I can leave without it, but maybe people will find it useful. maxim@ just pointed me at kern/97071, but I still see no strong need for it. The security.jail.mount_allowed when set to 1, grants PRIV_VFS_MOUNT, PRIV_VFS_UNMOUNT and PRIV_VFS_MOUNT_NONUSER privileges to super-user within a jail, but only for jail-friendly file systems. A jail-friendly file system is a file system with was registered (via VFS_SET(9)) with VFCF_JAIL flag. For now only ZFS registers itself with this flag, but we may want to consider adding VFCF_JAIL to nullfs/unionfs (and maybe NFS?:)). Comments, opinions? PS. Example use of jail services KPI can be found at: http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=3D//depot/user/pjd/zfs/s= ys/compat/opensolaris/kern/opensolaris%5fzone.c&REV=3D6 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Dzs2zDY0zgkG72+7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGD92sForvXbEpPzQRAkwjAKDQgUITNd6B9LThuYVA01fO9ETJngCgyFSe phwjYgbTdTxrsmcB1iiRfyU= =h2VJ -----END PGP SIGNATURE----- --Dzs2zDY0zgkG72+7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070401162828.GD25661>