Re: ide-cd problems

From: Jens Axboe
Date: Mon Aug 09 2004 - 03:53:44 EST


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/