Patrick McFarland wrote:
>I was refering to the 2.6 permissions bug in cdrecord. It wouldn't work using
>a non-root user, even if they had the correct permissions. 2.6 changed (for
>the better, mind you), and Joerg refused to fix cdrecord. (I don't know if
>its even fixed now). Theres been other cases of cdrecord breaking on Linux
>only, but I can't think of them atm.
Well, it seems that you are uninformed about the facts :-(
So let me quote a mail I send to LKML on Aug 17 13:14:59 2004:
/*--------------------------------------------------------------------------*/
If Linux believes that there should be enhanced security similar to Solaris and
if Linux is a true open Source business, then I would expect that there is
cooperation. If I change things in e.g. mkisofs or cdrecord that could result
in problems for my "users", I send a notification mail to the XCDRoast & k3b
authors early enough.
If Linux plans to implement incompatible changes, I would expect that
"important users" are informed in advance so that it is possible to discuss the
problems an to have a planned smooth migration. As this did not happen, the
change needs to be called a bug. This is even more obvious if we take into
account that cdrtools curently is in code freeze state as a 2.01-final will
come the next days.
For this reason, I would recommend that Linux immediately goes back to the old
behavior and informs "important users". A change that has effects that are as
widely as this one should not be tried again within the next 3 months. Then
there is a change to have a smooth migration......
BTW: I try to inform my "important users" more than a year before I introduce
important changes.
/*--------------------------------------------------------------------------*/
Note that this was a few days before cdrtools-2.01 final have been published
(after nearly two years of planned work on a new version).
The changes to Linux did neither fix the problem (just check the mailings on
LKML from last year) nor has there been a need for introducing incompatible
changes. If the cause for the change really was the "security problem" caused
by the fact that Linux did allow to send SCSI commands on R/O file descriptors
it would have been sufficient to require R/W permissions on the fd. After
this putative small change, the supposed problem would have been fixed and
cdrtools as well as other users of the interface did work as before.
What the change on Linux did was not to fix a problem but to break cdrtools.
I am not unwilling to fix cdrecored, as a non broken program does not need
a fix. I was even willing to add a workaround for the incompatible interface
change. But this may obviously not happen in a code freeze state.
Sorry - The problems between cdrtools and Linux is only a result of the
missing will for cooperation from the Linux kernel crew.
BTW: Due to missing time (I like to see a good cooperation between my work
and the support code in an OS, so I am now actively working on OpenSolaris
and I am very busy...). My planned OpenSolaris based UNIX distribution
"SchilliX" should be available soon after the public availability of the
OpenSolaris source in Q2/2005 which is only a few days from now. Fortunately,
I believe that I will be able to boot my first "SchilliX from scratch"
compiled CD today.
P.S.: About 10 days ago, I made an attempt to include a workaround for the
interface changes in Linux, check cdrtools-2.01.01a03
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On May 25, 2005, at 09:15:33, Joerg Schilling wrote:
> If Linux believes that there should be enhanced security similar to
> Solaris and
> if Linux is a true open Source business, then I would expect that
> there is
> cooperation. If I change things in e.g. mkisofs or cdrecord that
> could result
> in problems for my "users", I send a notification mail to the
> XCDRoast & k3b
> authors early enough.
There was a security hole in the CD burner support. The Linux Kernel
developers
fixed it quickly. They were not planning to wait 6 months for you to
get an
updated version of cdrecord out the door in any case. If you want more
information on the Linux Kernel security policy, please see a recent
copy of the
linux kernel for the file Documentation/SecurityBugs. To quote the
relevant
part: "It is reasonable to delay disclosure ... or for vendor
coordination.
However we expect these delays to be short, measurable in days, not
weeks or
months." Part of this policy includes "we'd like to know when a
security bug is
found so that it can be fixed and disclosed as quickly as possible."
This seems
to imply that the security team is not likely to wait 6 months to fix
a critical
hardware-damaging vulnerability.
> If the cause for the change really was the "security problem"
> caused by the
> fact that Linux did allow to send SCSI commands on R/O file
> descriptors it
> would have been sufficient to require R/W permissions on the fd.
> After this
> putative small change, the supposed problem would have been fixed
> and cdrtools
> as well as other users of the interface did work as before.
I will not debate this issue with you. Please see the copious
quantities of
emails when this issue was brought up a while ago.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$
r !y?(-)
------END GEEK CODE BLOCK------
Kyle Moffett <[email protected]> wrote:
> On May 25, 2005, at 09:15:33, Joerg Schilling wrote:
> > If Linux believes that there should be enhanced security similar to
> > Solaris and
> > if Linux is a true open Source business, then I would expect that
> > there is
> > cooperation. If I change things in e.g. mkisofs or cdrecord that
> > could result
> > in problems for my "users", I send a notification mail to the
> > XCDRoast & k3b
> > authors early enough.
>
> There was a security hole in the CD burner support. The Linux Kernel
> developers
> fixed it quickly. They were not planning to wait 6 months for you to
> get an
> updated version of cdrecord out the door in any case. If you want more
> information on the Linux Kernel security policy, please see a recent
> copy of the
> linux kernel for the file Documentation/SecurityBugs. To quote the
> relevant
Looks like you did not read the mail from me you were replying to.
The best way to fix a problem is to fix the problem and not to do something
else and to change the interface.
The problem was that you could send SCSI commands on R/O fds and fixing the
problem would have been to forbid sending SCSI commands on R/O fds.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, 26 May 2005, Joerg Schilling wrote:
> Looks like you did not read the mail from me you were replying to.
Let's start a technical discussion with a personal attack...
>
> The best way to fix a problem is to fix the problem and not to do something
> else and to change the interface.
When possible, correct.
>
> The problem was that you could send SCSI commands on R/O fds and fixing the
> problem would have been to forbid sending SCSI commands on R/O fds.
IT DOESN'T WORK THAT WAY. You *can't* disallow sending commands, that's
how you do a read on a SCSI device, by sending commands like "seek" and
"read." What is needed is to limit the commands allowed to be sent, and
pass only known appropriate commands depending on access.
It is true that the first implementation didn't have all the legitimate
commands in the table of allowed commands. But once the idea of doing bad
things to a CD by sending evil commands was well-known, it was important
to have protection in place quickly.
It is true that some developers have been very unhelpful, and replied with
canned "you don't have permission" messages to reports that legitimate
commands aren't in the allowed table.
It is true that the implementation is overly complex, instead of using
only read and write, other things are checked, resulting in some
unexpected behaviour, like blocking programs being setuid.
What is NOT TRUE is that any of this was done just to piss you off. That
was just a fringe benefit to fixing the security issue quickly. AFAIK all
of the commands for burning single session CD/DVD are working as intended.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thursday 26 May 2005 16:15, Joerg Schilling wrote:
> The problem was that you could send SCSI commands on R/O fds and fixing the
> problem would have been to forbid sending SCSI commands on R/O fds.
Unfortunately, this is not going to work. It would work only if the only app
that has to send SCSI commands were cdrecord. Then really, a non-setuid
program just would not be able to get a R/W fd, and setuid ones are assumed
to be trusted.
The problem is that many CD audio players also send SCSI commands in order to
extract digital audio data. Are you proposing to make them setuid root? use a
well-defined setuid helper? other solution?
--
Alexander E. Patrakov
"Alexander E. Patrakov" <[email protected]> wrote:
> On Thursday 26 May 2005 16:15, Joerg Schilling wrote:
>
> > The problem was that you could send SCSI commands on R/O fds and fixing the
> > problem would have been to forbid sending SCSI commands on R/O fds.
>
> Unfortunately, this is not going to work. It would work only if the only app
> that has to send SCSI commands were cdrecord. Then really, a non-setuid
> program just would not be able to get a R/W fd, and setuid ones are assumed
> to be trusted.
If these programs did rely on the named security bug, then these programs
were broken anyway and need to be fixed. Note that the _old_ (non ioctl based)
/dev/sg interface needed write access in order to send SCSI commands.
> The problem is that many CD audio players also send SCSI commands in order to
> extract digital audio data. Are you proposing to make them setuid root? use a
> well-defined setuid helper? other solution?
If these programs did ever work before, someone did break them meanwhile.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily