From owner-freebsd-security Sun Jan 7 8:51:50 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail1.javanet.com (mail1.javanet.com [205.219.162.10]) by hub.freebsd.org (Postfix) with ESMTP id 5C9BA37B69B; Sun, 7 Jan 2001 08:51:01 -0800 (PST) Received: from wintermute.sekt7.org (146-115-74-28.c5-0.brl-ubr1.sbo-brl.ma.cable.rcn.com [146.115.74.28]) by mail1.javanet.com (8.9.3/8.9.2) with ESMTP id LAA30510; Sun, 7 Jan 2001 11:50:56 -0500 (EST) Date: Sun, 7 Jan 2001 11:54:23 -0500 (EST) From: Evan S X-Sender: kaworu@wintermute.sekt7 To: Robert Watson Cc: Kris Kennaway , freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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