Date: Sun, 7 Jan 2001 11:54:23 -0500 (EST) From: Evan S <kaworu@sektor7.ath.cx> To: Robert Watson <rwatson@FreeBSD.org> Cc: Kris Kennaway <kris@FreeBSD.org>, freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel Message-ID: <Pine.GSO.4.10.10101071151580.5155-100000@wintermute.sekt7> In-Reply-To: <Pine.NEB.3.96L.1010107112140.27948E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mm, Openroot runs on -CURRENT, and users are able to apply those flags to files. But, I made a little patch, and it seems to work. They're not able to do it anymore. Other than that I'm happy with the way Jail works. The above was the only problem I had. Thanks, Evan Sarmiento (kaworu@sektor7.ath.cx) http://sekt7.org/es On Sun, 7 Jan 2001, Robert Watson wrote: > > 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 > robert@fledge.watson.org NAI Labs, Safeport Network Services > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10101071151580.5155-100000>