cdrecord Error (Permissions?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Mon, 2005-11-28 at 17:15 +0100, Ralph Angenendt wrote:
> That has been fixed in later versions of the kernel

There's no "fix."  The kernel now differentiates between suid root and
actually running as root, removing a lot of crucial access for the
former.  It was a very, very good security move IMHO.

Jorg's cdrecord just dies if it isn't granted certain priority, which it
assume it has if its running suid root as well as actually as root.  He
either needs to not crap out if the kernel denies him priority, or test
if the program is running suid and act accordingly.

> (no, it's not 2.6.8+, it's only 2.6.8 AFAIR) - and surely has been
> fixed on CentOS, as I do not have any problems burning CDs as a non-
> root user.

As I mentioned before, in the few extra months of the Red Hat Linux 9 to
Fedora Core 1 switchover, there were a lot of "sanity checks" done on
the packages.  From trying to map dependencies and reduce inter-RPM
dependency hell on the base packages to getting rid of a lot of back
security defaults -- the latter attitude removed suid on cdrecord.

As such, when Fedora Core 2 was updated to kernel 2.6.8.x+ with this
"kernel security change," it works flawlessly, without issue.  The issue
_only_ occurs if suid root is set on cdrecord.  RHEL 4 (and CentOS 4)
inherit these defaults.

> | [angenenr@shutdown ~]$ls -l /dev/hdc
> | brw-------  1 angenenr disk 22, 0 Nov  9 14:34 /dev/hdc
> I would think that udev does that for me.

The problem isn't with permissions, although Red Hat's console.perms
and, in FC3+/RHEL4+, udev handles setting up device access for the
console user proper.  Too many other distros just suid too many binaries
to bypass proper permissions on devices.

The problem is distros with ...  
  $ ls -la `which cdrecord`
  -rwsr-xr-x  1 root root 366944 Oct 18  2004 /usr/bin/cdrecord
     ^ suid root ^

On FC1+, you'll see:  
  $ ls -la `which cdrecord`
  -rwxr-xr-x  1 root root 366944 Oct 18  2004 /usr/bin/cdrecord

So when FC2+ came around (RHEL4 being based on FC3), and the 2.6.8.x+
update came out, *0* issues resulted.  Unless someone manually set suid
root on cdrecord.

The problem isn't device permissions.  It's the elevated priority that
Jorg's cdrecord tries to gain because it thinks its running as root.  It
craps out if they aren't granted.  Again, he either needs to A) not crap
out if they are not granted, or B) test for suid root on the cdrecord
binary and not request the additional kernel priority on kernel 2.6.8.x
+.

There is "no fix" for a "good security default."

[ Now I'm waiting for the countless people to compare this change to
SELinux and other things that "break past behavior."  ;-]


-- 
Bryan J. Smith   mailto:b.j.smith@xxxxxxxx
http://thebs413.blogspot.com
------------------------------------------
Some things (or athletes) money can't buy.
For everything else there's "ManningCard."



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux