Date: Mon, 21 Dec 1998 13:51:20 -0800 From: "Cliff Skolnick" <cliff@steam.com> To: "Eivind Eklund" <eivind@yes.no>, "Dag-Erling Smorgrav" <des@flood.ping.uio.no> Cc: "Matt Dillon" <dillon@FreeBSD.ORG>, <security@FreeBSD.ORG> Subject: RE: cvs commit: src/etc rc.conf Message-ID: <000201be2d2c$0b94baa0$2020a8c0@icarus.internal.steam.com> In-Reply-To: <19981221163532.G14124@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This sandbox stuff is starting to worry me :( The more FreeBSD changes stock daemons used on many other UNIX systems the harder it will be to respond to know bugs. For denial of service attacks often the sandbox will not help, if the daemon dumps core or becomes unusable it doesn't matter what UID it was. The sandbox changes a fundamental design of UNIX, and makes FreeBSD "different" than other UNIX systems. The difference in the short term may be more security, but in the long term FreeBSD daemons could become hopelessly out of sync with standard daemon distributions over time. It's one thing to change a few permissions and directory names, it's completely different to start passing file descriptors (which is only mildly portable) via a coprocess. If this stuff started to become standard FreeBSD it would be time to start looking for another OS IMHO. I want to run something close to a standard UNIX that works and is reasonably secure. The only total security is to turn the machines off. :) -- Cliff Skolnick Steam Tunnel Operations cliff@steam.com http://www.steam.com/ > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Eivind Eklund > Sent: Monday, December 21, 1998 7:36 AM > To: Dag-Erling Smorgrav > Cc: Matt Dillon; security@FreeBSD.ORG > Subject: Re: cvs commit: src/etc rc.conf > > > On Mon, Dec 21, 1998 at 04:25:08PM +0100, Dag-Erling Smorgrav wrote: > > Eivind Eklund <eivind@yes.no> writes: > > > ... unless you do a series of small modifications. It is not as if > > > rescanning the interfaces is a _large_ task, or one that couldn't be > > > done by a forked out half of named > > > > Umm, the problem isn't scanning interfaces, the problem is binding to > > them, which needs to be done by the parent, so you can't delegate > > interface rescanning to a child process. Or rather, you can, but it > > won't matter since at some point the child will need to communicate > > its results to the parent which will then attempt to bind to port 53 > > on interfaces it's not yet bound to, for which it needs privs. > > You don't need to have the parent bind the interface. You use the > capability transfer support in BSD - you pass an fd over a local > socket, using SCM_RIGHTS. > > This is described in the Stevens book, which is presently occupying > the space between your monitor and lamp (on the right side of the > monitor). The implementation of this mechanism is in > sys/kern/uipc_socket.c, sys/kern/uipc_syscalls.c, and > sys/kern/uipc_usrreq.c. > > Eivind. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000201be2d2c$0b94baa0$2020a8c0>