Date: Thu, 16 Apr 1998 15:29:32 +0000 From: Niall Smart <rotel@indigo.ie> To: Robert Watson <robert+freebsd@cyrus.watson.org>, freebsd-security@FreeBSD.ORG Subject: Re: securelevels and more liberal use of schg on system files (fwd) Message-ID: <199804161429.PAA02651@indigo.ie> In-Reply-To: Robert Watson <robert@cyrus.watson.org> "securelevels and more liberal use of schg on system files (fwd)" (Apr 15, 9:01pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 15, 9:01pm, Robert Watson wrote: } Subject: securelevels and more liberal use of schg on system files (fwd) > BSD/OS and others make use of securelevels in their production releases to > prevent time rewinds, etc. It may be desirable that FreeBSD do so in the > future. Currently, however, securelevels do little if anything to > actually increase the security of a system. I think this can be improved > through some careful thinking out of the issues, and would like to see > this happen in FreeBSD. :) All experimentation was performed on > 2.2-STABLE a few days ago. I agree that we aren't making enough of this feature. Securelevels are important in that for the average user who leaves the system at level -1 they will not affect him in any way, yet if he decides to bump the level up to 1 or 2 they can play an important role in enforcing the system security policy. To put this another way: any changes made to the securelevel system won't affect the majority of users out there who are running at level -1, so we can safely tighten up the policy without fear of making the system less convenient for the ordinary joe soap. [...] > Note that it is not init(8) itself that performs the sysctl activity, but > rather the rc(8) script. In a sense, it cannot be init(8), as the rc(8) > script later runs fsck(8) to clean the file systems, and it requires write > access to the block devices. However, this does leave us with a few > problems. Neither /etc/rc nor /usr/sbin/sysctl are protected by schg. > For that matter, neither is fsck, or any number of utilities used by rc(8) > prior to being able to raise the securelevel. While some of the above Good point. [...] > Additionally, while we notice that the files are protected against > modification (and links to them), the directories are *NOT*. /sbin/init > is schg, but the directory /sbin is not! Similarly with all of the other [...] > So there are some fairly severe problems with the current behavior of > FreeBSD with securelevel in use. Just to sumarize: > > 1) The set of files installed with schg is not sufficient for any > environment where file systems containing binaries are writable by > software (i.e., not a CD-ROM or a write-protected floppy). Even though > some of the required files are protected, their directories are not > protected in the default install. Default installs probably do not > benefit from having so many key directories (/usr/lib, /sbin, /etc) be > schg, but if securelevels are to be used, it must be published that they > cannot just be "turned on" as described in init(8). The default protections applied by make installworld seem to be rather half hearted alright. :) Anyone planning to run with securelevel >0 with the current install script would be well advised to supplement them. It would be very nice to see someone think through which binaries need to be protected as part of an overall brainstorming session about making securelevels useful. There are problems other than with file flags though, in particular there are many binaries with sgid kmem or suid root bits that really don't them. For example, ccdconfig(1), timedc(1). I don't know of any problems with these utilities, it's just that I am very reluctant to give a s[ug]id bit to a utility unless it absolutely needs it. I think this reluctance is justified by the problem which I found in ccdconfig and pointed out on BUGTRAQ some months ago. > 2) A read-only mount can be converted into a read-write mount without any > prevention of the kernel. With the use of chroot(8), life can be made > much harder for the uid 0 user when it comes to modifying key system > files. However, through creation of device nodes (which is permitted in > securelevel>=2) in mfs partitions, it may be possible to break out and > remount / read-write. The current policy for mounting/umounting > partitions in high securelevels may not be adequate, given the desire to > protect key system directories against attacks over a reboot. Yes, I think the ability to prevent mount -u rw on a ro fs is good too. > 3) Unmentioned above, the init search path in the kernel actual attempts > to run a series of possible programs: This shouldn't be a problem if the /sbin directory is tied down, should it? [...] > I am also interested to know why such an interesting array of commands is > schg -- for example, there is no reason why passwd(1) should be schg that > I can think of. Either way it aquires root access, or uses NIS. A uid-0 > user could easily compile there own. Presumably this is to allow > passwords to be changed safely after a penetration; this idea is probably > bogus. Perhaps the original intention was to prevent an intruder installing a bogus passwd utility allowing them to covertly monitor password changes on the system, thus gaining access to new systems. This would also explain the schg flags on login. Regards, Niall > Robert N Watson > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ -- Niall Smart. finger njs3@doc.ic.ac.uk for PGP key FreeBSD: Turning PC's into Workstations. www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804161429.PAA02651>