[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#56821: POSSIBLE GRAVE SECURITY HOLD]



On Sat, Feb 05, 2000 at 01:53:52PM -0500, Jacob Kuntz wrote:
> in the world of PCs, its not uncommon to be able to take over a system by
> rebooting it. i have always assumed that people realize that no matter how
> the software is configured, if you have access to the phisical hardware
> controlling it, you can do what ever you want with it. it's foolish to argue
> about this.

I've been following this thread and have de-cloaked long enough to
transmit these characters.  Warning: some of these phrases could be
misinterpreted as attempts to steer the discussion back on-topic :)


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.


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.


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.


Is it worth arguing about ?
===========================
I've seen a lot of posters whose have mentioned that securing the
console is not of huge importance, because its ultimately pointless.
Or saying that the floppy drives should be removed because they're
insecure.  Or saying the computers should be cased in steel.  i

While each of those methods is perfectly appropriate to some scenarios, 
the scenario of Thomas, the original poster, was a lab full of PCs with
floppy drives and "inquisitive" students.

My opinion is that this is an important (for the promotion of GNU/Linux)
and fairly common scenario which should be catered for, therefore their
needs should be given due consideration.

I think there is a big difference between a machine that can be 
compromised only by getting into the case and a machine which you can be 
compromised easily and quickly without doing anything which would look 
any different to normal computer usage to a casual observer or 
surveillance cameras.


Summary
=======
This I would say is a huge pro for security if we disable this behaiour 
by default.  I don't know of any arguments for enabling the behaviour,
but I'm not a security expert and I can't guarantee that I remember
every point that was made in each of this thread's post ... :-)
Can anyone give me an example of such a scenario ?

Regards,
Paul


> 
> i was however not made aware of mbr's capabilites when i read the install
> guide during my migration from slackware. this does need to be addressed.
> undocumented features suck.
> 
> -- 
> (jacob kuntz)                    jpk@cape.com jake@{megabite,underworld}.net
> (megabite systems)     "think free speech, not free beer." (gnu foundataion)
> 
> 
> --  
> To UNSUBSCRIBE, email to debian-bugs-dist-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-- 
Regards,
Paul


Reply to: