<!-- SBZ_reproduce  -->
-

Created attachment 23858 [details]
add struct file argument to block device ioctl

This is a prereq for doing read/write permission checks in SG_IO

Created attachment 23859 [details]
Add permission based command table to scsi_ioctl.c

Add current list of commands that are allowed for read open, write open, or
only users with CAP_SYS_RAWIO.

These are the two patches against SLES9-GA kernel. Please note that we also need
to update the cd burning programs at the same time, at least a few of them were
buggy in that they only opened the device O_RDONLY while they should have
acquired write permission. This wasn't a problem before this patch was added to
the kernel.

Thanks Jens for the fixes! 
 
Does it just affect cdrecord? Or do you know about others? 

Added on request from Jens: 
 
cdrecord should be ok, but k3b is not. dvd+rw-tools might need checking, 
too. and not just burning programs, also programs that use SG_IO for 
anything else - you need write permission for any command that transfers 
data to the drive, not just WRITE_* commands. 
 
SL92-beta should have these issues fixed, since that kernel already 
contains the extended command permission table 

I added the maintainers of k3b (AFAIK just a frontend for the command-line 
tools), dvd+rw-tools, and cdrdao to this bug. 
 
I think you are all aware of the changes needed for 9.2 because it's kernel 
already includes this patch. 
 
Does your code need patching for 9.1? 

cdrdao uses scsi library from cdrecord, so it is OK too. 

our version k3b should not have these issues anymore. 
 
jfyi, k3b uses the tools, but it does also open the devices for detecting the 
drives. 

Adrian, 
so after updating the kernel with Jens' patches k3b would still run or do we 
have to release a new k3b package for 9.1? 

we will make an official kernel update containing these changes for 9.1 ? 
 
yes, we would need definitive a new k3b than. 

Please, let's do some extensive testing. Last k3b version that I checked 
(~ 5 weeks ago) did not recognize the CD Recorder ... I believe this has 
been fixed since, but I must have missed the update package for SL91. 

please, talk we about 9.1 with an official kernel update which will break k3b  
or do we speek about 9.2 ? 
 
k3b on 9.2 does definitive work in general. Maybe not all flavors like CD-RW / 
DVD-RW and so on, but that should maybe get tested by our QA. 
 
Marco, did you tested all kind of medias ? 

Adrian never entered this for me on friday, so here it is:

We just need to provide updated packages with the kernel security
update. For the programs that have this bug, it's a one-liner fix. The
problem is not the fix, it's checking that all programs do the correct
thing and open the device O_RDWR for issuing SG_IO commands that write
to the device as well. Even things like controlling the volume on the
drive requires write permissions now.

I just was bitten by this problem myself now. It was solved by using the latest
kernel from SL 9.2. What exactly do we need to do to solve the problem for 9.1?

Hubert, what problem?

Ehm forgot to cc hubert. Please see comment #16.

the patch appears not to be in the SLES9-GA branch 

CAN-2004-0813 

I haven't added it, should I?

Yes, please go ahead ;)

The two patches are committed to -GA now. Who should I assign this security
issue to for further processing?

Also note that the subject of the bug isn't entirely correct - this issue
affects not just cdrom devices, but also SCSI drives of any kind.

GA branch update released. 
 
this just leaves the 2.4 kernels affected and I am not sure if we want to 
update those. 

2.4 kernels aren't affected through SG_IO. CDROM_SEND_PACKET is, though. But
that only works on CDROMs, not on hard drives and other SCSI devices.

i think in this case we can lay this issue at rest and leave 
the 2.4 kernels as-is and mark this issue fixed. 

CVE-2004-1190

CVE-2004-1190: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:N/I:P/A:N)