Date: Mon, 5 Jun 2000 12:11:43 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-security@FreeBSD.org Cc: trustedbsd-discuss@TrustedBSD.org Subject: cvs commit: src/sys/kern kern_mib.c kern_prot.c src/sys/sys systm.h (fwd) Message-ID: <Pine.NEB.3.96L.1000605120616.12201A-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
As part of a flurry of commits to FreeBSD 5.0-CURRENT relating to improved authorization structure, capabilities framework, et al, I committed a patch that adds a sysctl disabling suser_xxx(), the call that authorizes uid0 processes to make use of special privilege. Setting the sysctl at this point is not particularly productive, but can be an enlightening experience. To try out, cvs update or cvsup to the latest 5.0-CURRENT tree, and as root: sysctl -w kern.suser_permitted=0 An important note is that without capabilities present and appropriately configured, shutdown will panic the system as some processes die before init, which upsets the kernel. The current set of capabilities patches do not apply cleanly, and I need to go through and update for recent commits. Poligraph text should be out on the list by this evening now that I've had a chance to gather together a variety of comments. I invite criticism, discussion, and suggestions :-). 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 ---------- Forwarded message ---------- Date: Mon, 5 Jun 2000 07:53:55 -0700 (PDT) From: Robert Watson <rwatson@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern kern_mib.c kern_prot.c src/sys/sys systm.h rwatson 2000/06/05 07:53:55 PDT Modified files: sys/kern kern_mib.c kern_prot.c sys/sys systm.h Log: o Introduce kern.suser_permitted, a sysctl that disables the suser_xxx() returning anything but EPERM. o suser is enabled by default; once disabled, cannot be reenabled o To be used in alternative security models where uid0 does not connote additional privileges o Should be noted that uid0 still has some additional powers as it owns many important files and executables, so suffers from the same fundamental security flaws as securelevels. This is fixed with MAC integrity protection code (in progress) o Not safe for consumption unless you are *really* sure you don't want things like shutdown to work, et al :-) Obtained from: TrustedBSD Project Revision Changes Path 1.33 +25 -1 src/sys/kern/kern_mib.c 1.57 +3 -1 src/sys/kern/kern_prot.c 1.115 +2 -1 src/sys/sys/systm.h 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.1000605120616.12201A-100000>