Date: Thu, 14 Sep 2006 08:17:03 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: New in-kernel privilege API: priv(9) Message-ID: <20060914081703.umum0k4x3k88k4ko@webmail.leidinger.net> In-Reply-To: <20060913150912.J1823@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Robert Watson <rwatson@FreeBSD.org> (from Wed, 13 Sep 2006 =20 15:29:14 +0100 (BST)): > privilege list in src/sys/priv.h: > ... > PRIV_UFS_SETQUOTA, /* setquota(). */ > PRIV_UFS_SETUSE, /* setuse(). */ > PRIV_UFS_EXCEEDQUOTA, /* Exempt from quota restrictions. */ Is this something special to UFS, or did you use the UFS part only =20 because no other filesystem in the tree has support for quotas? > - It makes it possible for the MAC Framework to allow policies to grant > privilege. Policy modules can register interest in privilege checks, an= d > then specifically grant access to privileges as they see fit. > > In order to demonstrate MAC Framework integration with the privilege > system, I have implemented a sample policy module, mac_privs, which > allows rule-based granting of privileges to specific uids. Using a > command line tool, appropriately privileged processes can modify the > rule list, granting named privileges to unprivileged users. This is > not a particularly mature example of a privilege-granting policy, as > ideally privilege is something that is available but not always > exercised -- i.e., similar to a setuid root binary that switches the > effective uid to root only when it specifically needs privilege. > However, it's quite useful in practice, and demonstrates how > configurable policies can interact with kernel privilege decisions. > It is my intent, following review, discussion, cleanup, etc, to commit > the priv(9) work, sans mac_privs, to the 7.x tree in the next couple of > weeks. The mac_privs policy is a sample policy that will continue to be > maintained as part of the TrustedBSD Project, but not merged into the > base tree at this point. Is the mac_privs policy just a proof of concept? It would be nice to =20 allow more fine grained access to some users or applications. The =20 later one would need some way to identify the application/binary in a =20 safe way, maybe by using extended attributes in the FS. Bye, Alexander. --=20 Real programmers don't write specs -- users should consider themselves lucky to get any programs at all and take what they get. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060914081703.umum0k4x3k88k4ko>