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

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

On 12/17/05, Bastian Blank <waldi@debian.org> wrote:
> On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote:
> > On 12/16/05, Bastian Blank <waldi@debian.org> wrote:
> > > On Wed, Dec 14, 2005 at 01:54:45PM +0000, Ian Jackson wrote:
> > > > Are you saying that the current default permissions on (eg) /dev/hda*
> > > > are insecure and therefore wrong ?
> > >
> > > Yes, I overwrite them on my machines.
> >
> > And what is your reason for being unwilling to use the same procedure
> > on devmapper disks?
> Which procedure? You seem to know something I don't know. ("Overwrite"
> means in my context: chmod of static devices or a MODE setting in the
> udev config)

I'm trying to ask why you are unwilling to have devmapper disks provide
a default of root.disk 660?  Why can't you allow that to be the default?

Is there some reason you can't have implement your personally preferred
policy of root.root 600 on just your own system?  Is there some reason
for projecting your personal policies incompletely onto an arbitrary
subset of debian's users?

Is there something about this question I'm asking which doesn't make
sense to you?

> > Personally, I'm using a system where the only way to obtain root access
> > is to log in as root -- there's no privileges gained through suid binaries.
> Err? Write access to the device of a mounted filesystem is a way to gain
> root if you don't disable several options.

Quite a bit of stuff doesn't work the way you might normally expect, on that
particular system.

Anyways, good security means that the system works the way the person
responsible for the system think it's supposed to be working.

What you've done here introduces surprises and thus would tend to
degrade the security of debian users's systems (not directly but by
requiring that some people introduce ad-hoc and perhaps ill-considered

You seem to be asserting: "a malicious person who handles backups could
use the disk group to obtain root access, so you should force backup programs
to run as root."  But that does not seem to be a reasonable position:

(1) There are risks other than a malicious people -- by ensuring backup programs
don't have to run as root, we minimize the risks that such programs will do
something they weren't designed to do.

(2) A malicious person with physical access to the system can compromise
it in a variety of ways (boot with init=/bin/sh, replace the OS, add monitoring
hardware to the keyboard or the display, put a logic sniffer on the bus, etc.

As things currently stand:

(A) The risk you're protecting against is not defeated by the measures
you propose.

(B) The measures you propose have not been accepted (or even discussed)
in the debian community at large.

(C) You've defeated some measures which make debian systems more

(D) You've clearly stated that you do not require that devmapper use these
defaults to implement your security policy.

I don't have any right to object to how you maintain your own personal systems,
but what you're inflicting on debian as a whole does not seem to make much


Reply to: