Joerg Schilling wrote:
Bill Davidsen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]