Re: join us!

[jpenny@universal-fasteners.com]

On Thu, Aug 31, 2000 at 10:26:20AM -0600, Kurt Seifried wrote:
> BTW Idon't know if anyone actually "got it" but the point of my article was
> more that Debian is trying to improve security, but seems to be missing
> major things. I suppose I should have stated this more obviously (like in H1
> at the top). Sigh, anyways for next time I will be less subtle. Bruce
> Schneier's new book (secret's and lies) covers this too, people view
> security as a number of small unrelated problems, when in fact you have to
> treat it as an entire, complex, system. For example: Protecting boot up:
> 
> Problem: User can boot off off removable media
> Solution: Change BIOS settings, Debian can't really do this, however they
> may wish to document it. I have at:
> http://www.securityportal.com/lskb/10000000/kben10000001.html

OK, 2 to 5 minutes downtime to disable.  Big Whoop.  Maybe should be
done.  But, have you ever tried to administer 200 computers?  How many
people know the BIOS password?  Do the primary users know it?  Can they
reboot their own machine?  Does an administrator have to visit every
machine every time it needs to be rebooted?  Do you write down lists
of 200 passwords?

> 
> Problem: user can enter Lilo commands at the Lilo prompt
> Debian's solution (partial): install sulogin, thus requiring user to enter a
> root password for runlevel 1, this still allows the user to enter command
> arguments however.
> Real solution: use "restricted" and "password", set lilo.conf mode 600, now
> the user must get root to read file or some other exploit to read file (then
> they could read /etc/shadow, or whatever as well).
> Additional solution: remove/replace password in lilo.conf after setting it
> (i.e. set password, run lilo, remove password).
> 
> Problem: users with physical access can compromise security.
> Yes but there is a big difference between hitting ctrl-alt-del, tryping
> "Linux init=/bin/sh" then making them bring a boot disk, or if you locked
> the BIOS down stealing the machine/etc. I love visiting computers labs with
> Linux machines, I have yet to find one where lilo was restricted/password
> protected yet, many use sulogin, but that doesn't work so well.
> 

This is actually one of only two reasonable points in the discussion.
The other point was that better documentation is needed.

> As you can see booting the computer (even looking at it in pure overview
> terms) is quite complex and there are many interactions (i.e. OS security is
> pointless if the attacker has a boot disk and can use it). However with a
> few simple steps you can plug all the holes possible short of sending a
> debian representitive to the persons house/business to install debian
> securely for them. The effort put into sulogin would have been better placed
> in making the install script go "would you like to protect boot up
> blahblahblah Y/n:" followed by "set a lilo password:". As I pointed out to
> one person using sulogin and not securing Lilo is like putting a nice
> expensive dead bolt lock on a screen door.
> 

I take it then that you have now retracted the version-itis 
(use the latest version no matter how many new holes may have been
introduced) argument.  I see no mention of the "I didn't install
MD5 because I can't read recommendations during the setup process", so,
are we down to nothing but the LILO setup?  (And the need for more
documentation?)

> Kurt Seifried
> SecurityPortal, your focal point for security on the net
> http://www.securityportal.com/
> 
> 
> 
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>