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

[Paolo Bonzini <pbonzini@redhat.com>]

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.
> 
>> http://permalink.gmane.org/gmane.linux.kernel/1254625 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.

Paolo