[ On Tuesday, June 12, 2001 at 23:53:44 (+0200), Matthias Buelow wrote: ]
> Subject: Re: ctrl+alt+del
>
> Because I did not have superuser privileges, of course.

That begs the (rhetorical) question -- why were you responsible for the
outcome and why didn't the superuser take care of it?

If you were just an ordinary unprivileged user then you shouldn't be
allowed to reboot the system no matter what.  If you have complete
physical access to the entire machine then you should have a root
password (or at least a Kerberos instance that gives you root on that
machine).  There is really no sane middle ground.  If you don't have
complete physical access to the machine then you're not responsible for
it and someone else should have the root password and they should manage
the OS on it for you.

I.e. if a "public" workstation doesn't allow anyone to login as root on
the "console" then it shouldn't allow a reboot from there either (at
least not without an authorised user issuing the root password to 'su'
or similar).

> It is not really feasible on Unix to restrict users in a way that
> the accumulated memory of all their processes does not fill up system
> resources.

Well I beg to differ, at least for *BSD.  There are things the current
implementation of resource limits cannot do on *BSD, but it is in fact
very easy to ensure that a user cannot fill up all system resources.
It's just a matter of understanding the system and doing the math right.

Unfortunately systems are often configured by default to allow a single
user to make use of all resources.  This works well with co-operating
users who don't abuse their resource utilisation and who share the
system, but it doesn't work when you've got anyone being a bit of a pig
and not playing fairly.  If more than two adversarial users are given
simultaneous access to the same system then that system really must be
reconfigured to ensure it imposes necessary limits on those users.

>  You'd need something like per-user virtual memory limits,

We have that already in some sense.  It's (RLIMIT_NPROC * RLIMIT_DATA).
As an unprivileged user you just can't slide to allow more of one in
return for fewer of the other.

> like on, for example, VMS, which is not typically available in Unix
> (and not in NetBSD either, from what I understand.)  Restricting the
> maximum number of processes and individual process size limits so that
> the product will never exceed a desired global per-user limit gives
> you either very few processes only, or very low memory limits per
> process, or both.

You should be able to configure a system that will have enough VM to
support a reasonable configuration of users and process limits.  Indeed
the Sparc-20 I spoke of is configured in such a way that several users
could have tried the same "attack" and yet I still would have been able
to login on the console and kick them off.

The real problem is that BSD gives the user so many opportunities to
over-use his or her share of the system.  Sometimes this is OK because
such over-use is temporary and does not conflict with the resource
requirements of other users.  However on a multiuser system there are
far more opportunities for co-ordinated attacks by many users.

It's very much similar to the problem of allowing bursting on a packet
based network.  When you compare VMS facilities (or perhaps those of any
real mainframe system) against those of Unix you're comparing something
like Frame Relay to Ethernet.  I.e. it's apples and oranges.

Now of course the network analogy is poor because there's no superuser
on the Ethernet (at least not on a basic LAN) who can go in and clamp
down on an abusive station.  On unix there's always an extra process
slot for the superuser and an extra little bit of VM, disk space, etc.
The superuser should always be able to login and kill of an offender.

I don't think it would take too much more work to add a per-user
accounting of VM utilisation and implement additional resource checks
that would allow restriction of the total memory resources used by a
user across all of his or her processes.  The same hashed list used for
cngproccnt() (i.e. struct uidinfo) could no doubt be expanded to handle
this.  However the additional accounting overhead may not be worth the
effort -- perhaps it would always be too much for a generic system.

> Just for the records, I have reported this as kern/7714 in 1999.
> The PR is still open and I don't think there really is an easy solution
> to this.  I'll try it later that week if the problem still persists.

It's certainly not an obvious problem on -current, at least not with a
properly configured system.  It may still be a problem on the release
branches where VM over-commit is perhaps easier to trigger.

In that PR you mentioned that your system had only 256MB of swap.
That's probably not anywhere near enough and I wouldn't be surprised if
it still did over-commit on 1.4 with that few resources, especially
using GNU grep.  The sparc-20 I did that same test on has 287MB RAM and
about 1.5GB of swap (on the one and only disk spindle).  Because of the
way the *BSD VMs usually work and the way user limits are usually
configured I always make sure my systems have far more swap than they
could hopefully ever need or use.

You should be sure that a single user cannot trigger a VM over-commit
before you test again.

I don't know if the VM over-commit problem has really been fixed even in
-current or not, so perhaps a co-ordinated attack by several users
against the sparc-20 could still cause it to actually lock up.  (My
second test just now caused a "panic: malloc: out of space in kmem_map"
just as I was killing off the last few grep processes, but that's a much
different problem than a lock-up.  We'll see in a day or two whether
today's -current still suffers the same way and if so I'll send-pr.)

Indeed sometimes a reboot is a "quicker fix", but unless the system is
misconfigured in the first place it should never be actually necessary.

(i.e. this is not a valid excuse for wanting "ctrl+alt+del" support! :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>