Date: Mon, 7 Jul 1997 21:10:00 -0400 (EDT) From: Adam Shostack <adam@homeport.org> To: rnw@andrew.cmu.edu (Robert N Watson) Cc: freebsd-security@FreeBSD.ORG, tech@openbsd.org Subject: Re: Security Model/Target for FreeBSD or 4.4? Message-ID: <199707080110.VAA21941@homeport.org> In-Reply-To: <Pine.SUN.3.93l.970707141837.17888A-100000@apriori.cc.cmu.edu> from Robert N Watson at "Jul 7, 97 02:47:12 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Robert N Watson wrote: | | On Mon, 7 Jul 1997, Adam Shostack wrote: | | > I brough up the idea of doing this on the openbsd list. We agreed | > that there wasn't a clean way to do it. I'm experimenting with ways | > of doing it, leaning towords a sysctl controlled list of port, gid | > pairs. I don't know of anyone who has implemented it. | > | > The overhead should be pretty minimal. | > | > I chose not to depend on files, which is ugly, but not so ugly as | > having the kernel depend on files during startup. | | My assumption was a default boot config of only root being able to bind | <1024, but then using syscall adding port,uid pairs. I'm not sure what | all the connotations of using port,gid vs port,uid are -- gid does seem to | be a better idea, as it seem to fit the existing daemon, mail, bin, www, | groupings, and in the context of FreeBSD's default matching of one group | per uid, it is just as flexible. Are there any other issues involved | here? What daemons would end up running as the same user? fingerd could | run as nobody (or a finger user) as it needs minimal access. bind, for | example, would benefit more from a seperate dns user (which would be nice | also when it comes to implementing a secure resolver and key management | system), and sendmail could finally run as group mail, user mail (?) and | just have the local delivery agents run as suid root? Not sure what all | the implications are there, either. Some rewriting of code would have to | take place, and that might not work as well. My thought was that you could make programs setgid portbind. Seems intuitively cleaner than making them setuid something. Also, allows you to have a simple implementation with just a list of ports that portbind can bind to (dns, http). I'd leave everyone under a different user who can't do anything, to avoid having daemons running kill each other. As far as sendmail goes, I think that if you use setuid procmail as your delivery agent, sendmail doesn't need to be root. (Use qmail!) | > The other thought that has occured to me, but I expect it to be more | > expensive, is to use a packet filter with NAT capabilities to | > translate port bindings to high numbers for appropriate daemons. | > Since this has a per packet hit, I expect it to be very expensive on | > an ongoing basis. | | I had also hoped for something a little more flexible/portable, or | something based a little more on a traditional interface to the system. I | also considered a less open approach to port permissions -- requiring that | all port binding in any range be permitted by a system-wide policy. Under | such a system, rc.ports would be called by the rc boot sequence (prior to | going multi-user) to enable binding access for various gids or uids using | sysctl. When the securelevel increased, the default permissions for | binding a port would change from default-permit (except <1024) to | default-deny, meaning that only explicitely permitted services would be | disabled. One can argue that this might cause more prolems than it | solved, as it would effectively cripple many of the more useful UNIX | daemons, not to mention normal user applications :). In particular, you | would lose portmapper-related utilities, not to mention UDP-based query | services (like DNS.) Obviously, such an implementation would require a | much more significant rewrite of user-side code, and is not feasible for | general-release systems in the short term. Well, the question also to ask is the value of all this work? I think you get a fair bit of benefit from creating a portbind group, and then the additional benefits give you progressively less value for your time. I don't think that a general port control facility is as worthwhile; the system is the way it is because the implementors decided not to bother pushing it through the filesystem, and fixing it properly will take a fair bit of work. | Well, just some speculation. Finding an elegant way to implement | permissions on ports would be nice. Since the filesystem is the | traditional approach to permissions, maybe we should be looking at that as | a mechanism, similar perhaps to /proc. This seems a bit redundant given | that sockets already have a filesystem representation.. Really? I must have missed it.. Adam -- He has erected a multitude of new offices, and sent hither swarms of officers to harrass our people, and eat out their substance.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707080110.VAA21941>