Re: [06/07] [PATCH] SCSI tape security: require CAP_ADMIN for SG_IO etc.

Kai Makisara
2005-04-28T05:41:10Z

On Wed, 27 Apr 2005, Alan Cox wrote:

> On Mer, 2005-04-27 at 18:16, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
>
> This patch is just wrong on so many different levels its hard to know
> where to begin.
>
> 1. The auth for arbitary commands is CAP_SYS_RAWIO

Valid complaint.

> 2. "The SCSI command permissions were discussed widely on the linux
> lists but this did not result in any useful refinement of the
> permissions." - this is false. The process was refined, a table setup
> was added and debugged.

Any user having write access to the device is still allowed to send MODE
SELECT (and some other commands useful for CD/DVD writers but being
potentially dangerous to other). The assumption that _any_ command needed
for burning CDs/DVDs is safe for all device types is ridiculous. This is
why I don't consider the refinements useful.

Controlling high-level access and pass-through with the same permissions
is not a very good model.

> Someone even wrote an fs for managing it that is
> not yet merged.

Yes. So we should wait for a miracle happen and it get merged? My patch
is meant to fix the problems at low level until a more general fix is
merged (if that ever happens).

> Perhaps the patch author would care to re-read the
> archives and submit a new patch if one is even needed
> 3. Pleas explain *what* the specific consistency problems are

OK. Once again....

Using MODE SELECT you can change the drive behaviour so that it may become
practically useless for other users (and even break very quickly). A
simple method is to disable drive buffering. The inconsistency here is
that to the users the drive status is not what the system managers meant
it to be.

Another inconsistency comes from using commands moving the tape so that
the tape driver does not know it. The tape driver provides users some
status information about the tape head location (file and block number,
BOT, EOF, etc.). This information is not valid if tape is moved using
pass-through. The basic problem is that the driver for this kind of a
sequential access device has to maintain some state information and it
gets distorted if pass-through is used. One solution would, of course, be
to interpret the commands and statuses going to/coming from pass-through
but this is a quite heavy solution.

OK. If the Linux solution to these kind of security problems in the not so
central areas of kernel is to wait and see if the problem disappears
without any action, I have to accept that. But I have tried...

--
Kai