Date: Wed, 09 Feb 2005 17:24:26 +0000 From: Colin Percival <cperciva@freebsd.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_jail.c src/sys/sys jail.hsrc/sys/ufs/ufs ufs_vnops.c src/usr.sbin/jail jail.8 Message-ID: <420A474A.1050901@freebsd.org> In-Reply-To: <20050208215041.GP1080@darkness.comp.waw.pl> References: <200502082131.j18LVBBd031393@repoman.freebsd.org> <20050208215041.GP1080@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > On Tue, Feb 08, 2005 at 09:31:11PM +0000, Colin Percival wrote: > +> Add a new sysctl, "security.jail.chflags_allowed", which controls the > +> behaviour of chflags within a jail. If set to 0 (the default), then a > +> jailed root user is treated as an unprivileged user; if set to 1, then > +> a jailed root user is treated the same as an unjailed root user. > > More than that. It should be allowed in the future by default Don't you think it's better to err on the side of security? There are certainly times when allowing a jailed user to manipulate system file flags could cause (non-obvious) problems, while any failure caused by an inability to set these flags will be immediately obvious. Also, I'm planning on MFCing this to RELENG_5, and we definitely don't want the default behaviour to change there. > and this > behaviour should be controlled by jail's securelevel. Right now with security.jail.chflags_allowed=1, the usual securelevel restrictions apply based on both the host and jail securelevel. Is this what you meant? Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?420A474A.1050901>