Date: Tue, 8 Jul 1997 11:45:57 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Adam Shostack <adam@homeport.org> Cc: freebsd-security@FreeBSD.ORG, tech@openbsd.org Subject: Re: Security Model/Target for FreeBSD or 4.4? Message-ID: <Pine.BSF.3.95q.970708113714.4712A-100000@cyrus.watson.org> In-Reply-To: <199707080110.VAA21941@homeport.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jul 1997, Adam Shostack wrote: > > 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!) Running the daemons as different users would be a must, but using a common portbind group could allow a web server to prevent proper mail service by binding the port at an appropriate time (e.g., the mail server reloads, but the penetrated web server binds the port, as it has rights to do, which allows it to intercept all mail, and deny service, etc.) Similarly, if the web server runs as www.portbind, all cgi programs inherit binding rights to any of the reserved ports, and that is a bad thing. While portbind sounds like a good simple setup, I'd like to see the facility that allows us to link (port,protocol) to a specific gid. Possibly a specific interface, if there is a clean way to do that (so that different web servers running virtual domains could run as different users, and not be allowed to interfere with one-another, etc.) E.g., this web server is only allowed to bind to 127.0.0.1:80, not 127.0.0.2:80. With regards to sendmail -- the only program with a lack of suid on sendmail is local mail delivery: pine (and others) rely on calling /usr/sbin/sendmail -etc if not using smtp (and not all clients support smtp). That sendmail attempts to deliver, but if it fails, puts it in /var/mqueue (possibly more complicated behavior here), and cannot do that if it is not suid-something (could be made sgid mail?) For actual delivery, mail.local is already suid-root, I believe. This continues to be fine behavior as far as I'm concerned. > 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. I don't debate the diminishing returns theory, but I think diminishing returns may be more of an issue if we push socket permissions onto the file system in /.../inet/tcp/port, etc, than a gid/port pair list. With regards to gid vs. uid -- is either one of this preferable for any particular reason? gid may be more flexible, I guess, as it would allow multiple users to bind the same ports, but without having rights to each others processes, and as such allow a simpler minimum configuration. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970708113714.4712A-100000>