Bug#56821: POSSIBLE GRAVE SECURITY HOLD]
My turn to uncloak long enough to say something, but hopefully not long
enough to get flamed to hell and back.. :)
[Begin snipfest]
-----Original Message-----
From: Paul J. Keenan [mailto:paul@funkiest.demon.co.uk]
Sent: Saturday, February 05, 2000 3:00 PM
To: Jacob Kuntz; 56821@bugs.debian.org
Subject: Bug#56821: POSSIBLE GRAVE SECURITY HOLD]
[Skipped Bits]
Documentation
=============
Thomas does read the documentation, when it is provided. It sounds like
he has given a lot of thought and put some work into his current setup,
yet he was still bitten. From my understanding of the context, I can't
say that I would not have been bitten too.
Providing good documentation includes writing good docs, and linking to
other relevant documents. There appears to be a problem here, so if it's
not been fixed already, then it should be addressed by the package
maintainer of whatever package should be providing updated manpages ASAP.
[Snip!]
I believe Mr. Di Carlo et al have already addressed this to some extent with
boot-floppies 2.2.6.. I haven't looked at their fix yet, so I can't speak
authoritatively on it. But essentially, what we have here (in my opinion)
is NOTHING more than am up-front documentation issue.
[Unsnip]
Security policy
===============
Every reasonable admin knows that with unrestricted access to a machine's
hardware, the data is insecure. Both sides are in agreement, and so let's
stop regurgitating it.
I assume that Debian's position on security would be that security should
be maximum unless the overhead of that security is prohibitive, e.g. if
we lose any features or flexibility. There is a tradeoff, and each
secutity issue should aim for a "reasonable" point in the tradeoff.
[Snip]
Arguments about security policy seem moot, unless we splinter Debian into
two separate dists, one focusing on developers and hobbyists, and one
focusing on secure server environments... The requirements for both are
quite different. (NetBSD vs OpenBSD, anyone?..)
[Unsnip]
Should the feature be enabled by default ?
==========================================
(refering to the feature of allowing boot from floppy even though
the BIOS protection has done everything in it's power to prevent
this)
What are the pros and cons of enabling this feature by default ?
What are the pros and cons of disabling this feature by default ?
Beased on the answers to those, lets argue constructively and
decide whether to change or keep things the same.
[Snip]
Enabled by default: Good for recoverability of system, etc. This is good
for the developer and hobbyist crowd, who no doubt hose their systems on a
regular basis by accident. :)
Disabled by default: System recoverability becomes a bit more of a pain, but
security becomes tighter.
Personal conclusion: Turn it on by default with big flashing warning lights
about reading the docs (t'would be nice if it pointed to where the docs
are), if you are setting up a secure system.
[Unsnip]
[More missing bits: blah, blah.. Thomas's situation not that unique, blah,
blah... mbr insecure, etc..]
Regards,
Paul
[Final Snip]
Thanks for your input Paul... Maybe this will get the discussion back where
it belongs, or kill it completely... Either way, that's a good thing.. :)
When half my inbox is labeled "POSSIBLE GRAVE SECURITY HOLD" I start to get
annoyed.
Basically, I see this as something that really shouldn't be all that
difficult to fix in boot floppies.
"Do you want a really flexible mrb that allows you to do funky things like
boot from non-active partitions and floppy disks (read the docs in
/usr/share/doc/mbr), or do you want to install LILO as your mbr for added
security (note, you should read LILO's docs and learn to secure it with a
password, etc.)"
Answer: "Funky mbr" or "LILO mbr"
Just my two cents...
-Adam
Reply to: