Bryan J. Smith wrote:
> 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.
>
> 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." ;-]
>
Thanks Bryan and Ralph. Suid was set on cdrecord, I believe I did
this on accident while testing something out with cdrecord and
basically shot myself in the foot. Thats what happens when you
follow a guide without question.
Appreciate the information and help. That was very informative
Bryan, much obliged.
Thanks!
Alex White
