Re: Need help
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 :-(
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).
Check out "man privileges" on Solaris for more information on what makes a
ready to use system in this area.
On Solaris, cdrecord really runs without root privileges. On Solaris,
/usr/bin/cdrecord is a shell script with the following content:
#!/bin/sh
pfexec "`dirname $0`/`basename $0`.bin" "$@"
The file /etc/security/exec_attr contains the following entries for cdrtools:
Basic Solaris User:solaris:cmd:::/usr/bin/cdrecord.bin:privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr
Basic Solaris User:solaris:cmd:::/usr/bin/cdda2wav.bin:privs=file_dac_read,sys_devices,proc_priocntl,net_privadd
Basic Solaris User:solaris:cmd:::/usr/bin/readcd.bin:privs=file_dac_read,sys_devices,net_privaddr
Once Linux implements a user ready version of the current experimental
interface, it would make sense to let cdrtools use this interface.
> > 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".
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.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: