Date: Wed, 4 Oct 2000 08:14:21 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: Dima Dorfman <dima@unixfreak.org>, Alfred Perlstein <bright@wintelcom.net>, Mike Silbersack <silby@silby.com>, security@FreeBSD.org Subject: Re: BSD chpass (fwd) Message-ID: <Pine.NEB.3.96L.1001004080541.3436E-100000@fledge.watson.org> In-Reply-To: <20001004025836.A84165@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Oct 2000, Kris Kennaway wrote: > mounting is still allowed at all securelevels, so you could also null > mount over the top of /usr/bin even if /usr/bin is schg. The fact that > you can mount volumes at high securelevel seems to mean there is no > way you can protect a running system against tampering with a given > file (i.e. replacing the runtime-visible instance of a given file). > > Robert Watson would probably start talking about MAC about now :-) but > I'm not sure if this is something which should be fixed as a security > problem, or if it is just not practical to expect securelevels to > prevent run-time tampering of a given file (leaving aside the issues > of protecting the boot path against taking control of the machine at > next reboot time, which only happens as a result of incomplete > coverage of the relevant files and directories with schg) Heh, you know me too well. (Either that, or I talk too much :-). As Kris points out, securelevels are generally unable to provide the level of security that they promise without effectively crippling the system. I would generally advise that people not rely on securelevels providing more than ``best effort'' improvements in the event of a root compromise: as someone point out (Dima?), securelevels are great for confusing script kiddies, but a qualified and knowledgeable attacker can bypass their protection given root privilege. To be honest, I'd like to see the last vestiges of the securelevel concept in userland (the schg flag on some binaries) be made optional in the installworld process, as it not only doesn't provide bullet-proof protection, but does impede portable upgrades across file system types (try doing an installworld on an NFS mounted file system). The script kiddie puzzling element is certainly entertaining, but should be optional :-). There are a number of structural improvements that could be made to securelevels and our boot process to correct some of these issues, but I think a more general solution is needed. Two goals of the TrustedBSD project are to (a) reduce the target presented by the "root" user by breaking out privilege in a modular fashion, and (b) provide a system integrity policy that is capable of protecting access to privilege (especially kernel privilege) in the face of compromise of some parts of the system. Hopefully, the resulting system will be easier to use and manage than properly implemented securelevels, but I would suspect still harder to manage than a normal UNIX system. As the features will be optional, I think that's an acceptable trade-off. If there are people interested in discussing this further, I'd welcome participation in the trustedbsd-discuss mailing list :-). 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 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.1001004080541.3436E-100000>