Date: Sun, 17 Dec 2000 14:39:32 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-security@FreeBSD.org Cc: freebsd-arch@FreeBSD.org Subject: Removing #ifdefs on LOGIN_CAP? Message-ID: <Pine.NEB.3.96L.1001217143505.48123N-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
As part of the mandatory access control implementation, I'm using the capabilities database (/etc/login.conf) to add label information to user classes; in this manner, each user is mapped to appropriate mandatory policy restrictions and rights. To do this, I've introduced LOGIN_SETLABEL as an option to setusercontext(), which extracts the labeling information, and applies it to user processes at login. This has a number of impacts -- first, it requires that programs use setusercontext() when working with user context information, rather than manually diddling with uid's, which is probably a good thing. It also requires the programs start correctly using LOGIN_SETALL rather than manually contructing masks (a bit of work -- I updated su to do this a couple of weeks ago, but work remains to be done in other programs). This raises the following issue: currently, the login capability code is ifdef'd by LOGIN_CAP throughout the source tree, and in many cases, alternative implementations of context management code exist in an #else. Do we know if anyone still uses the old code? Would there be any objections to transitioning to only using setusercontext() and the login capabilities database rather than retaining the old implementations, giving us a consistent implementation throughout and allowing the capability database to hold additional per-user/class security properties? I also plan to use login.conf to hold information on privileges (capabilities) that users are allowed to acquire via su as well as configuring per-user audit properties, so there are other applications that will use this also. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001217143505.48123N-100000>