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

[Kai Makisara]

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
-
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/