Re: join us!
On Thu, 31 Aug 2000, Kurt Seifried wrote:
> [snip] ... people view security as a number of small unrelated
> problems, when in fact you have to treat it as an entire, complex,
> system.
I agree. I also think that good security needs to involve research. I
think it's Debian's responsibility to provide secure packages, but I don't
expect them to handhold me through the installation and configuration
process. There's far too many possible configurations for them to guess
at what is appropriate for me.
When I want to secure a system, I research it. I check man pages. I look
in /usr/doc. I surf the web. I look for books. In short, I do what I
can to find out how this system works. After I've read some, I
think. Given my setup, how will changing X affect me?
I don't expect someone else to do this for me. My security is my
responsibility.
> 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
Does everyone need to document this? It already is, in many places. In
fact, I consider it common knowledge.
> 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).
I agree with you 100% here. sulogin is a half-assed solution.
...
> 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.
Hmmm... my lab has for more than a year now. All our computers are set to
boot from the hard drive only, BIOS has a password set, LILO has
"restricted/password" set... all non-needed services are turned off...
packages are updated to exploit-free versions (as far as I know,
anyway)... anything I'm missing here?
Actually, I think NFS is out biggest security problem. As far as someone
can write down a lab computer's IP, bring their own computer in, and mount
our NFS shares, they'd get full access to everyone's home directories. We
need something better, but that's an entirely different discussion.
> 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.
Maybe that deserves to be filed as a bug.
-Matt Stegman
<mas9483@cis.ksu.edu>
Reply to: