1 |
Lindsay Haisley posted <20041024150011.GC9486@×××.com>, excerpted below, |
2 |
on Sun, 24 Oct 2004 10:00:11 -0500: |
3 |
|
4 |
> I posted my problem to the gentoo bug tracker, and there's been a bit of |
5 |
> traffic on it. Seems there was an overhaul of SCSI in kernel 2.6.8 which |
6 |
> may have caused the problem. I have 2.6.9, and when I get time (after Nov |
7 |
> 3rd or 4th) I'll try it and see if the problem is solved. |
8 |
|
9 |
Yes. That overhaul of SCSI was due to the security issues I mentioned. |
10 |
Since you are able to sudo to root, that should work for doing your |
11 |
burning. |
12 |
|
13 |
The SCSI changes were after 2.6.8-rc2, IIRC, which I ran for awhile as a |
14 |
result, keeping 2.6.7 around as well, as the last full release I could |
15 |
run without the changes. However, I decided I could go root too, to do my |
16 |
burning, and am now on 2.6.10-rc1, the latest. |
17 |
|
18 |
As I mentioned, eventually, there will be a finer security filter set for |
19 |
the various SCSI functions and burning from non-root should be possible |
20 |
again. However, figuring out all the implications of each individual |
21 |
SCSI command function and how it might be used in the various instances, |
22 |
then nailing it down as safe for non-root use, unsafe for non-root use, or |
23 |
safe for non-root use ONLY with certain devices (optical disks but not |
24 |
hard drives, for instance) and setting it up so the selection of "certain |
25 |
devices" is both secure and functional, PLUS testing those changes, is |
26 |
several month's work, particularly when one considers the fact that such |
27 |
large scale changes to the SCSI system would have to be vetted to LKML and |
28 |
suggestions from others on the list incorporated into the final solution. |
29 |
Thus, late this year at the earliest, spring next year more realistically. |
30 |
|
31 |
In the mean time, a decision was made to mark an entire class of SCSI |
32 |
functions as root-only, not able to be called by SETU/GID executables, and |
33 |
security updates to cdrecord and the like changed the privs of formerly |
34 |
SETU/GID executables such that they were safe even on non-updated kernels, |
35 |
basically breaking burning functionality for non-root users entirely. As |
36 |
I said, the window of breakage is looking to be about a year. |
37 |
|
38 |
Thus, current sysadmins are left with a choice of allowing non-root users |
39 |
to use the system with old "insecure" versions, if all users are trusted |
40 |
and an exploit is thought unlikely enough to be worth the risk, or only |
41 |
allowing it for users that can become root, with a fully updated system. |
42 |
For systems where all human users are trusted to the point of being |
43 |
allowed access to root already, keeping updated is certainly the best |
44 |
choice. For those where that isn't the case, it would depend on whether |
45 |
non-root users really NEED that burning ability, or if they can ask |
46 |
an admin that has said ability to do the burn. Of course, as time goes on |
47 |
and additional updates are added, the insecure choice becomes insecure for |
48 |
other reasons as well, and the pressure to either switch to root-only |
49 |
burning or for those that have the ability, custom patch their kernels and |
50 |
apps to revert to old behavior, becomes greater. |
51 |
|
52 |
-- |
53 |
Duncan - List replies preferred. No HTML msgs. |
54 |
"They that can give up essential liberty to obtain a little |
55 |
temporary safety, deserve neither liberty nor safety." -- |
56 |
Benjamin Franklin |
57 |
|
58 |
|
59 |
|
60 |
-- |
61 |
gentoo-desktop@g.o mailing list |