Date: Mon, 18 Dec 2000 13:47:18 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-arch@FreeBSD.org Subject: Re: Removing #ifdefs on LOGIN_CAP? Message-ID: <Pine.NEB.3.96L.1001218133417.71838C-100000@fledge.watson.org> In-Reply-To: <200012181833.NAA22274@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett, I've CC'd the answer to your question back to -arch, because I think it's highly relevant, and not a point I meant to gloss over in my request of consideration of the LOGIN_CAP issue. On Mon, 18 Dec 2000, Garrett Wollman wrote: > <<On Sun, 17 Dec 2000 14:39:32 -0500 (EST), Robert Watson <rwatson@FreeBSD.ORG> said: > > > 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 > > What about all the programs which need to swap user identities? Well, the answer to that question very much depends on why it is the program needs to swap user identities. In many cases, setusercontext() will do the right thing, since they won't switch back and forth -- for example: login, su, sendmail, cron, inetd, and so on. Other programs are setuid to root so that they can exercise privilege and override system protections (such as ping, which requires a raw socket, or ssh, when using a low port number). In my TrustedBSD implementation, this is dealt with by using POSIX.1e capabilities to provide access to privilege rather than uid/gid diddling. There is a further set of programs that make use of setuid or setgid to provide mediated access to a shared resource -- for example, out setgid man and setuid lpr. In the first case, the goal is to make use of a shared cache in a controlled manner -- in the second, it's to make use of a shared spooling area. In both situations, there are clear weaknesses involved in making use of the setuid and setgid schemes, but also benefits. The same services can by addressed through daemons on IPC sockets, to a large extent, but one feature of setud/setgid binaries is that they inherit the full environment of the user process, and so can do things that are made very difficult through a controlled IPC channel -- for example, man has no problem understanding that it must run in a chroot() or jail(), and what that means. lpr has no problem with the current working directory; and piping all print files through IPC may be undesirable for many sites, when simply copying the file into the spool area with privilege provides much better performance. However, given the presence of new security policies, it's not clear that these setuid or setgid binaries even continue to gain the privilege necessary to perform their function by virtue of changing uids or gids. With a Biba integrity policy protecting users and the system, just runnings as gid man doesn't mean you can write to the man cache directories, at least not if you want a process with a higher grade to read from the cache directory. We'll have to address these issues seperately. I'd like to migrate all the programs that literally manipulate user or login contexts to using well-defined entry points for doing so, reducing code redundancy, as well as the opportunity for inconsistency and error. It also opens the door for additional work relating to PAM and user context management with information sourced from directory services, which is nice. That will probably mean leaving some tools setuid and setgid while we work on a better answer. 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.1001218133417.71838C-100000>