Date: Sun, 19 Apr 1998 12:40:31 -0700 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, Philippe Regnauld <regnauld@deepo.prosa.dk>, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Message-ID: <199804191941.MAA23123@cwsys.cwsent.com> In-Reply-To: Your message of "Sun, 19 Apr 1998 14:09:43 EDT." <Pine.BSF.3.96.980419132625.18223B-100000@trojanhorse.pr.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> I think I may not have expressed my proposal in the best possible way. My
O.K.
> following might work:
>
> -1 - fsck, mount first few file systems, clean up mess
> 0 - install ipfw filters, start logging daemons, etc
> 1 - ... (lock down on mount changes)
> 2 - ... (lock down on network config changes)
> (etc)
> x - raise network interfaces
The BSD kernel normally starts out at securelevel 0. Once init has
initialized, e.g. run the rc scripts, the kernel automatically raises
the securelevel to 1 if it hasn't been raised to a higher securelevel.
Securelevel -1 is a special case. If securelevel -1 is hard coded into
the kernel, as is done in FreeBSD, the kernel will not automatically
raise the securelevel. In short, securelevel -1 tells the kernel to
leave the system at a securelevel 0 state permanently.
What you're suggesting here is breaking the existing semantics.
Currently the securelevel semantics are,
-1 = permanently insecure mode, always run at securelevel 0 regardless
of
the system state (this must be compiled in the kernel, otherwise
securelevel 0 is used during boot)
0 = temporarily insecure mode, immutable and append-only flags may be
turned off; and all devices may be read/written.
1 = secure mode, immutable and append-only flags cannot be cleared,
mounted
disks and kernel memory are read-only.
2 = highly secure mode, same as securelevel 1 except all disks are
read-only
regardless whether they are mounted or not.
For this discussion securelevel -1 is irrelevant. Securelevels > 2 are
not defined, however as stated earlier in this discussion the kernel
does disallow altering of the ipfw configuration at securelevel > 2. I
would think that the designers of the BSD kernel probably had planned
to expand on the securelevels in a future release, had they had the
opportunity to.
What does all of this mean? It is clear to see that the BSD designers
had only documented filesystem semantics when describing securelevels.
We also see from the example quoted from ip_fw.c that securelevels > 2
were being considered by the BSD designers. Is it possible that
securelevels 0-2 are to address local security and securelevels > 2 are
to address network security.
Here is an alternative strawman,
-1 - permanently insecure, never used on a secure box (used for most
desktops and home systems)
0 - insecure mode, start all daemons, mount all filesystems
1 - BSD secure mode (described above)
2 - BSD highly secure mode (described above)
3 - Network secure mode, ipfw and network interfaces cannot be
altered
after they have been raised, routing tables cannot be altered
4 - Ultra secure mode:
/, /usr, /opt remounted read-only (by the kernel), no
mounts/umounts
possible, raw disk devices cannot be read,
NFS requests no longer honoured
5 - Ultra Ultra (for the lack of a better name) secure mode,
stack becomes non-executable
don't honour setuid bit (?), arp cache can no longer be altered
(?)
... - and so on...
Any thoughts?
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: cschuber@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Government of BC
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?199804191941.MAA23123>