Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Feb 2000 22:24:33 -0500 (EST)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Brian Fundakowski Feldman <green@FreeBSD.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c
Message-ID:  <Pine.BSF.3.96.1000219220444.55314A-100000@fledge.watson.org>
In-Reply-To: <Pine.BSF.4.21.0002192150120.71349-100000@green.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000219220444.55314A-100000>