On Sun, 7 Jan 2001, Evan S wrote:

> Mm, I want secure level to be 2 at times because then I can chflags schg
> the login.conf file inside the Jail, and limit cpu usage, memory usage,
> incase anyone fork bombs.
>
> That's alright though, I am working on giving a jail its own secure level,
> and its going pretty well..

At least in -CURRENT, processes within a jail should be unable to
manipulate the system file flags, meaning that from that perspective, jail
should already appear to have a lower securelevel. The goal of this
change from the original jail code was that this would allow the
administrator to share files between jails and have some confidence that
this would not be a channel of communication or attack between the jails.
I believe this was backported, so you may want to confirm, on a plain
vanilla system, that a change is actually required there.

Which features (other than the device-opening one which I pointed out in a
prior e-mail) have you identified which do not work under securelevels,
but do work in jail()? In general, features disabled were selected on two
criteria:

1) The ability to use the feature to "break out of securelevels" -- i.e.,
   influence the running kernel, or replace the kernel and its supporting
   files. This means protecting kmem, providing a system immutable file
   service, monotonically increasing securelevels only, and so on,
   directly access disk devices, and so on.

2) At higher securelevels, the ability to change security-sensitive system
   configuration. For example, the ability to change firewall rules.

There are probably some other miscellaneous securelevel details, but not
many. It should be noted that there is substantial overlap between (1)
above, and the goal of jail(), which was:

1) Prevent processes within jail() from being able to "break out of jail"
   -- that is, influence the running kernel to remove the restrictions in
   place, influence processes outside of the jail() in question,
   protecting against inappropriate direct disk devices access, and so on.

Therefore, it's arguable that jail() protections and securelevel
protections should have a lot of overlap, although some protections are
done in different ways. Securelevels prevents opening of devices, whereas
jail() limits the creation of devices (and assumes the administrator is
careful about which devices are created in the jail() namespace). Jail()
sharply limits a number of operations that are permitted with
securelevels, such as manipulating the file system namespace using
chroot() or mount(), whereas securelevels allow this to some extent.
Jail() has process namespace scoping, but securelevels have no need for
this functionality. Both securelevels and jail() limit certain
configuration activities, but for different reasons: jail() usually
restricts them because they impact processes outside of the scope of the
jail(). If you identify things restricted by securelevel and not jail(),
we should be considering changing jail() to be more restrictive.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robertfledge.watson.org NAI Labs, Safeport Network Services

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]