Re: [PATCH] scsi: Silence unnecessary warnings about ioctl to partition

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

Il 02/05/2012 13:12, Alan Cox ha scritto:
>> Sure, but then disallowing the ioctls for processes with CAP_SYS_RAWIO
>> will not cause regressions and _can_ happen.  The transition period only
> The user has CAP_SYS_RAWIO, they can already do it by poking the
> registers on the chip directly. It is a nonsense to attempt to block or
> warn about this.

Not true, for example CAP_SYS_RAWIO is still subject to access control.
 Even simple Unix DAC can prevent you from issuing register writes to
/dev/sdb, while letting you do so on /dev/sda and access /dev/sdb1.  I'm
not inventing anything, the old ATA subsystem is already blocking most
"dangerous" ioctls for partitions, even if you have CAP_SYS_RAWIO.

Now of course CAP_SYS_RAWIO lets you use ioperm or iopl, but that's a
separate issue and only limited to x86.

>> up and implement a very restrictive filter for SCSI commands sent to
>> partition.
> The process has CAP_SYS_RAWIO it can already bypass any check you try and
> put in place.

Almost any capability can be abused to bypass checks.  True,
CAP_SYS_RAWIO is especially good at that, but still you can try.

>> The right patch is one that prepares for these step,
> Doesn't look very right to me.
>> for example.  It
>> leaves the warning only for SG_IO, and silently blocks the rest (more
>> rationale in the commit message there).
> Even the printk in that patch is wrong. We have capabilities. Being a
> "root" user is a meaningless distinction here so your ratelimited printk
> isn't just bogus - its wrong. It may have got into RHEL somehow but the
> kernel QA process is a bit higher standard than this proposed patch.

Indeed, RHEL doesn't have the warning at all and blocks all ioctls
including SG_IO (and in the past six months nobody has complained that
something stopped working for them).  Never said the patch is perfect...

> A process with CAP_SYS_RAWIO has total power. It's assumed to know what
> it is doing. Trying to block it doing stuff like that simply makes
> authors do them via different more crass methods.

Getting appropriate permission on device nodes is less crass than
abusing partition device nodes.

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photos]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

Add to Google Powered by Linux