From owner-cvs-all Sat Feb 19 19:23:42 2000 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 30E4337BE24; Sat, 19 Feb 2000 19:23:36 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id WAA55401; Sat, 19 Feb 2000 22:24:33 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sat, 19 Feb 2000 22:24:33 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Brian Fundakowski Feldman Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Sat, 19 Feb 2000, Brian Fundakowski Feldman wrote: > On Sat, 19 Feb 2000, Robert Watson wrote: > > > rwatson 2000/02/19 17:10:38 PST > > > > Modified files: > > sys/ufs/ufs ufs_vnops.c > > Log: > > Disable chflags() from within jail() so that root within jail can't make > > a mess in securelevel environments. Results in one warning during > > /etc/rc as it attempts to remove file flags, but this is harmless. > > > > Maybe a silly question... why isn't it disabled in a jail only when the > securelevel that certain level which disables un-schging something? I actually suggested the option of making this a sysctl when I initially emailed phk/jkh for approval to make this change, but this didn't seem to spark any interest. The general principle of jail is that of least privilege, giving ``root'' in a jail only the very minimum capabilities necessary for things to still run in the jail. This least-privilege approach seems about the only way to sanely handle a feature-set like jail in a complex and changing environment such as FreeBSD. From the perspective of giving the host environment control of the contents of a jail, limiting the use of file flags makes sense, as it prevents the contents of a jail from limiting the ability of host administrators to reach into the jail. It also allows administrators to make use of schg (and others) to limit how the jail environment can make changes to its filespace--for example, using schg, the host administrator can prevent consumers of the jail from making changes to certain files, etc. In the absence of flexible namespace management (functional unionfs, loopbackfs), schg and friends also make it safer for administrators to reduce the disk load of jails by hard-linking common files between jails. That said, if you can think of a few legitimate (i.e., real-world) reasons for allowing the use of file flags in a jail environment in the manner you describe, I can go ahead and make it toggleable in some form using a sysctl. As with the jail.set_hostname_allowed sysctl, it's easy to see how different environments might want to use jail differently. As jail code development has been driven by a number of specific real-world environments, and not the desire for a general-purpose feature set, we'll probably see some more differences in how different consumers think specific policy decisions should be made. I actually like this approach--driving jail changes based on real-world environments means less stagnating code, and code paths actually being tested :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message