Date: Sun, 7 Jan 2001 11:32:28 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Evan S <kaworu@sektor7.ath.cx> Cc: Kris Kennaway <kris@FreeBSD.org>, freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel Message-ID: <Pine.NEB.3.96L.1010107112140.27948E-100000@fledge.watson.org> In-Reply-To: <Pine.GSO.4.10.10101070929330.5113-100000@wintermute.sekt7>
next in thread | previous in thread | raw e-mail | index | archive | help
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.NEB.3.96L.1010107112140.27948E-100000>