[883] in NetBSD-Development
Re: NetBSD configuration for dialup
daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Jul 21 18:24:08 1995
Date: Fri, 21 Jul 1995 18:14:53 -0400
From: John Hawkinson <jhawk@MIT.EDU>
To: mhbraun@MIT.EDU
Cc: ghudson@MIT.EDU, hartmans@MIT.EDU, bug-dialup@MIT.EDU, pc-dialup@MIT.EDU
> >> The Decstation dialups certainly don't have any of the measures you
> >> suggested here (except lack of a packet filter, and AFS in the
>
> Currently, the dialups hace their srvd mounted readonly. Becasue of
> a bug in Utrix, it is oftem impossible to unmount the /srvd with the
> machine multiuser, so we already have to go singleuser to make some
> modifications. In addtion to this, the dialups havec an integrity
> checker that compares files to knwon states, so if the klogin were
> modified, it would require atleast some work to change the
> prototypes.
Are you suggesting that you wish to *maintain* the current of
bringing the machine to single user to do maintainence functions,
or not?
Under BSD44 (and hence NetBSD) you have option of using
features like immutable files and such -- if you don't want to, you
certainly don't have to.
> >> On the practical side, conversations with Charles have left me with
> >> the impression that NetBSD security levels aren't very airtight right
> >> now, so it's probably not worth using them until they are.
>
> I would be interested in a quantification of this. especially a
> comparision with the other platform we are planning to try out,
> solaris.
That seems fairly easy. Under NetBSD "security levels" control what
the root user can do. Whether root can read from /dev/kmem, write to
raw devices, load kernel modules, etc. The current state of NetBSD is
such that there are a few ways to get around this protection, for
instance I believe some SCSI driver code makes it possible to access
arbitrary pieces of memory as root, bypassing the securelevel
functionality. That doesn't mean it's useless, but it certainly isn't
uncompromisable. Nevertheless, it's a damn sight better than Solaris,
which doesn't even attempt to provide this sort of functionality.
I think everyone agrees that you don't want bpf in the kernel :-)
Regarding the AFS loadable kernel module (LKM), it started out life as
a regular piece of the kernel, and I believe it could be put back that
way without a lot of work. Nevertheless, Yoav's point that you cannot
load LKMs in multiuser mode is correct, and I think that's good
enough. Particularly because the AFS LKM is maintained as an LKM, and
I don't think we really want to keep up a parallel development track
for it...
I think booting off of a floppy is a little extreme. Most of the security
measures are there to make it so you MUST reboot in order to do severe
tampering. People notice when machines reboot. If that happens for an
unexplained reason, that's when you go and start looking for problems.
Here's a summary of the secrelevels from the init(8) manpage:
The kernel runs with four different levels of security. Any superuser
process can raise the security level, but only init can lower it. Secu-
rity levels are defined as follows:
-1 Permanently insecure mode - always run system in level 0 mode.
0 Insecure mode - immutable and append-only flags may be turned off.
All devices may be read or written subject to their permissions.
1 Secure mode - immutable and append-only flags may not be changed;
disks for mounted filesystems, /dev/mem, and /dev/kmem are read-
only.
2 Highly secure mode - same as secure mode, plus disks are always
read-only whether mounted or not. This level precludes tampering
with filesystems by unmounting them, but also inhibits running
newfs(8) while the system is multi-user.
I disagree with Sam that we want to run in [2] -- that would mean that
/var would not be writable, precluding the writing of logs, etc., etc.
to local disk.
--jhawk
