The patch at the end is against 2.6.11.8.
The kernel currently allows any user permitted to access the tape device file
to send the tape drive commands that may either make the tape drivers internal
state inconsistent or to change the drive parameters so that other users find
the drive to be unusable. This patch changes ioctl handling so that SG_IO,
SCSI_IOCTL_COMMAND, etc. require CAP_SYS_RAWIO. This solves the consistency
problems for SCSI tapes. The st driver provides user-accessible commands to
change the drive parameters that users may need to access.
The SCSI command permissions were discussed on the linux lists and solutions
enabling different rules for different devices were suggested. However, none
of these has been implemented in the current kernel. It may very well
be that the tape drives are the only devices that users are sometimes given
permissions to access and that have security problems with the current command
filtering. This patch solves the problem for tapes and no more elaborate
patches are needed. If those are merged to the kernel, this patch can be reversed.
Signed-off-by: Kai Makisara <[email protected]>
--- linux-2.6.11.8/drivers/scsi/st.c 2005-03-03 21:10:36.000000000 +0200
+++ linux-2.6.11.8-k1/drivers/scsi/st.c 2005-04-30 09:57:21.000000000 +0300
@@ -3414,7 +3414,10 @@ static int st_ioctl(struct inode *inode,
case SCSI_IOCTL_GET_BUS_NUMBER:
break;
default:
- i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
+ if (!capable(CAP_SYS_RAWIO))
+ i = -EPERM;
+ else
+ i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
if (i != -ENOTTY)
return i;
break;
On Sat, 30 Apr 2005, Kai Makisara wrote:
> The patch at the end is against 2.6.11.8.
>
> The kernel currently allows any user permitted to access the tape device file
> to send the tape drive commands that may either make the tape drivers internal
...
> filtering. This patch solves the problem for tapes and no more elaborate
> patches are needed. If those are merged to the kernel, this patch can be reversed.
>
> Signed-off-by: Kai Makisara <[email protected]>
>
> --- linux-2.6.11.8/drivers/scsi/st.c 2005-03-03 21:10:36.000000000 +0200
> +++ linux-2.6.11.8-k1/drivers/scsi/st.c 2005-04-30 09:57:21.000000000 +0300
> @@ -3414,7 +3414,10 @@ static int st_ioctl(struct inode *inode,
> case SCSI_IOCTL_GET_BUS_NUMBER:
> break;
> default:
> - i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
> + if (!capable(CAP_SYS_RAWIO))
> + i = -EPERM;
> + else
> + i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
> if (i != -ENOTTY)
> return i;
> break;
Please hold this patch. Testing the corresponding patch for 2.6.12-rc
showed that this is too restrictive. Best to wait until the next versions
will be reviewed on the linux-scsi list and merged into -rc.
--
Kai
On Sun, May 01, 2005 at 08:56:06PM +0300, Kai Makisara wrote:
> On Sat, 30 Apr 2005, Kai Makisara wrote:
>
> > The patch at the end is against 2.6.11.8.
> >
> > The kernel currently allows any user permitted to access the tape device file
> > to send the tape drive commands that may either make the tape drivers internal
> ...
> > filtering. This patch solves the problem for tapes and no more elaborate
> > patches are needed. If those are merged to the kernel, this patch can be reversed.
> >
> > Signed-off-by: Kai Makisara <[email protected]>
> >
> > --- linux-2.6.11.8/drivers/scsi/st.c 2005-03-03 21:10:36.000000000 +0200
> > +++ linux-2.6.11.8-k1/drivers/scsi/st.c 2005-04-30 09:57:21.000000000 +0300
> > @@ -3414,7 +3414,10 @@ static int st_ioctl(struct inode *inode,
> > case SCSI_IOCTL_GET_BUS_NUMBER:
> > break;
> > default:
> > - i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
> > + if (!capable(CAP_SYS_RAWIO))
> > + i = -EPERM;
> > + else
> > + i = scsi_cmd_ioctl(file, STp->disk, cmd_in, p);
> > if (i != -ENOTTY)
> > return i;
> > break;
>
> Please hold this patch. Testing the corresponding patch for 2.6.12-rc
> showed that this is too restrictive. Best to wait until the next versions
> will be reviewed on the linux-scsi list and merged into -rc.
Ok, when you come up with something that is acceptable, care to email it
also to the [email protected] people?
thanks,
greg k-h