Re: Need help

[Bill Davidsen <davidsen@tmr.com>]

Joerg Schilling wrote:
> Bill Davidsen <davidsen@tmr.com> wrote:
>
>   
> > > cdrecord works without real problems on Linux-2.6 if you install it correctly
> > > suid root.
> > >   
> > >       
> > Unfortunately "run everything as root" is not going to happen on many 
> > systems, some years ago capabilities were added to Linux, and those are 
> > the proper way to do access rather than bypassing all security checks. 
> > Also, the last time I looked the notes you provided only worked if 
> > security was disabled, selinux won't let you do what you were suggesting.
> >     
>
> Looks like you are uninformed :-(
>   

I know about capabilities.
> Currently there is no more than something in pre-alpha state that could later
> become a fine grained security modell (once there is support in userland).
>   

You are confused. NSA selinux and capabilities are two totally different 
things. Capabilities have been in Linux since somewhere in 2.2, and are 
hardly pre-alpha.
> Check out "man privileges" on Solaris for more information on what makes a 
> ready to use system in this area.
>   
I'm discussing the shortcomings of cdrecord under Linux.
> Once Linux implements a user ready version of the current experimental
> interface, it would make sense to let cdrtools use this interface.
>   
The capability library has been around for years.
>   
> > > Some old versions do not but this is caused by non-cooperative acting
> > > from the Linux Kernel maintainers: they did introduce a severe incompatible 
> > > interface change after cdrtools had been put into a code freeze state 
> > > for releasing.
> > >       
> > Caused by fixing a serious security issue... Once the first exploit was 
> > out it did have to be done quickly, and it did impact applications (not 
> > just yours). It came at a bad time in your code cycle, but making it 
> > sound as if the change was made just because they felt like it is simply 
> > not true. Allowing any SCSI command to go to devices was a hole allowing 
> > the bad guys to wipe out firmware on hard drives as well as burners, and 
> > had to be stopped immediately.
> >     
>
> You are again uninformed: The security issue was: "sending of SCSI commands 
> was possible on file descriptors opened with O_RDONLY". The correct fix
> for this security bug was to require "O_RDWR" instead of "O_RDONLY".
>   

That is like saying that I have to open a file for read and write just 
to read it. Most people don't think allowing general write permission of 
raw devices is a "correct fix."

The correct fix was to allow a program to write SCSI commands (such as 
seek and read) with O_READ, but not to let other commands through. And 
it did take some time to get the list of allowed commands correct for 
the general case. And there are cases where odd vendor commands are 
blocked to non-root. Agreed it's not perfect, but it does keep people 
from reconfiguring the firmware when given read access.
> This did not harm interfaces but cure the problem. The problem was that
> Mr. Torvalds did introduce an incompatible interface change instead although
> many people on LKML did send their protest mails.
>   

Given a choice of more security or more convenience, I choose security. 
I don't insult people who make other choices, their priorities may be 
different from mine. The choice was made to default to restricted, and 
allow several methods to change that choice.

--
bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979