Re: ide-cd problems

[Jens Axboe <axboe@suse.de>]

On Sat, Aug 07 2004, Alan Cox wrote:
> On Gwe, 2004-08-06 at 15:32, Jens Axboe wrote:
> > That's the case I don't agree with, and why I didn't like the idea
> > originally. That suddenly requires a patching of the kernel because of
> > new commands in new devices. Like when dvd readers became common, you
> > can't just require people to update their kernel because a few new
> > commands are needed to drive them from user space.
> 
> I'm stunning we are even having this argument. You are talking about
> what appes to be a hardware destruction enabling security level bug in
> the 2.6 kernel and arguing about whether it is a feature or not.

Alan, stop putting words into my mouth. I'm not saying it's a feature.

> In essence you are saying read access to any raw device node entitles
> the opener of the file to destroy the attached device (device even not
> just media). You are arguing that its ok that I can use raw scsi I/O to
> subvert the read/write permissions too.

In essence, yes. I'm arguing that it's not easily doable to
differentiate between destructive and non-destructive commands. And that
doing so requires extensive tables because commands are not the same
across devices.

I'm not saying that I think it's a good thing! Or a feature, for that
matter. I'm just arguing the feasibility of doing it, the maintenance
involved, etc.

> In the example code I gave
> 
> >               default:
> >                       if(capable(CAP_SYS_RAWIO))
> >                       /* Only administrators get to do arbitary things
> */
> > 
> 
> means there is no need to recompile anything, you just need priviledges
> to do stuff the kernel doesn't *know* is safe. This is the correct
> behaviour for people who don't live in cloud cuckoo land.

I'm well aware of the implications. The argument is only whether it's ok
to policy filter unknown commands. I guess with capability elevating the
app until the kernels are modified it would be ok, at least it enables
the apps to work for root.

-- 
Jens Axboe