Date: 18 Oct 1999 18:30:20 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: Jacques Vidrine <n@nectar.com> Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <xzp67043a3n.fsf@flood.ping.uio.no> In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 10:21:47 -0500" References: <XFMail.991015111802.shelton@sentry.granch.ru> <Pine.LNX.4.05.9910150036170.5339-100000@jason.argos.org> <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <xzpyad12jd7.fsf@flood.ping.uio.no> <19991018043039.B1711@semiotek.com> <xzpso392gj0.fsf@flood.ping.uio.no> <19991018142633.D1DDB1DA3@bone.nectar.com> <xzp90503esj.fsf@flood.ping.uio.no> <19991018152147.609F71DA3@bone.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques Vidrine <n@nectar.com> writes: > On 18 October 1999 at 16:49, Dag-Erling Smorgrav <des@flood.ping.uio.no> wrote: > > What EE suggested was to define a new SYSCTL macro to make defining > > new security sysctls trivial. You'd do something like this: > [snip] > That's fine for system-wide stuff, but I'd like to see the ability > to tweak this same stuff per-process. Yes, I was coming to that 8) > I see a system-wide data > structure to hold this type of configuration information. Each process > should also have a pointer to the system-wide structure (or NULL) that > can be overridden by a system call such as jail. Or we could hang > this stuff off of the jail structure or something like it. Why are you so obsessed with jail(2)? There is no reason for this to be jail(2)-specific. As I told you on IRC: 03:21 #bsdcode Nectar> DES: securelevel == systemwide, jail == process based 03:22 #bsdcode ---------> nectar: no, you're not ambitious enough 8) What you want is process-level capabilities, which are inherited from parent to child. Init(8) starts out with all capabilities enabled; its child processes can then give up capabilities they do not need, but never gain any back. User-level capabilities can be implemented with relative ease by modifying setusercontext() et al. to tune capabilities according to login.conf. This is not entirely trivial to implement; one has to be very careful not to open huge security holes (by not revoking capabilities when one should). The safest path is probably to introduce a new syscall, e.g. setuid2(), which preserves capabilities, and have the legacy setuid() revoke *all* capabilities, so that programs which rely on setuid() to drop privileges will not suddenly become security liabilities. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no 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?xzp67043a3n.fsf>