Date: Mon, 7 Jul 1997 14:47:12 -0400 (EDT) From: Robert N Watson <rnw@andrew.cmu.edu> To: Adam Shostack <adam@homeport.org> Cc: freebsd-security@FreeBSD.ORG, OpenBSD Mailing List <tech@openbsd.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? Message-ID: <Pine.SUN.3.93l.970707141837.17888A-100000@apriori.cc.cmu.edu> In-Reply-To: <199707071803.OAA08144@homeport.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. A few more comments on implementing port-binding permissions: Verifying permission on a port would require high-order operations, even allowing for hashing: any attempted bind to a <1024 port would require many comparisons against gid, etc. Would we require the only gid be compared be the first in the gid list? Just to throw out another idea I had floating around, which may not be a useful one: would a /ports filesystem mapping be useful for permissions? All ports < 1024 would have a filesystem entry, and permissions on the port file would determine whether they could be bound or not (possibly overkill on the whole concept, but if we're trhowing around extending the socket facilities..) Additionally, maybe permissions on port access could be applied to other port ranges than <1024. For example, we could prevent non-root users from binding port 6000-6010, preventing a local denail of service attack. (not very useful, but..) A stricter security policy could then optionally be implemented. I'd rather not have users clog up ports 6000-6010, as they could prevent an X server for running, or break X forwarding in ssh, so could add a requirement that root access be used to bind that port. Again, the securelevel + sysctl could be used to determine the default action. 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.. Robert Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.93l.970707141837.17888A-100000>