Re: Samsung DVD writer.
Dave Platt <dplatt@radagast.org> wrote:
> Would you be willing to provide a specific and complete list
> (e.g. in a text file, as part of the cdrtools distribution) of
> the set of SCSI commands that you consider to be necessary
> and/or desireable for cdrtools? If the commands were listed
> all in one place, it would be much easier for people (Linux kernel
> maintainers, non-Linux kernel people, and J. Random Kibitzers)
> to do a proper security analysis, and then (as necessary) make
> a clean decision as to which commands are truly safe for non-root
> write access and which may not be.
I am not sure about your intention...
Whether is real interest and what you expect to change.
If you did look at the source, you did discover that it is writte
in a systematic way and that is is easy to fetch this list as all
SCSI commands are set up via
scmd->cdb.*cdb.cmd = 0x??;
lines.
If you write a simple commad line, you get this for cdrecord:
04 0B 0D 1B 1E 23 25 2B 35 3B 3C 42 43 44 46 4D 51 52 53 54 55 59 5A 5B
5C 5D A1 A6 AA AC AD B6 BB BF C1 C3 C6 C7 CE CF DF E0 E1 E2 E3 E4 E5 E6
E7 E9 EA EB EC ED EE F0 F1 F2 F3 F5 F6 F8 FB
this for readcd:
0B 0D 1B 1E 23 25 28 2B 3 35 3C 42 43 44 46 51 52 53 54 55 59 5A 5B 5C
5D A1 A6 AA AC AD B6 BB BE BF d8 E5
and this list for cdda2waw:
0B 0D 1B 1E 25 28 2B 35 3C 42 43 44 47 51 52 53 54 55 59 5A 5B 5C 5D
A1 A6 AA AD BB be BF C5 d4 d8 E5
> This list could either be done by enumerating the commands which
> are necessary, or could be done by saying "All of the MMC-3 commands,
> except for the following", or somewhere in between. The critical
> thing would be to have a fully-described list of the commands,
> independent of the current source-code implementation of
> cdrtools or any other software package.
>
> In looking at the Linux code which implements the security
> rules, I can see at least two things which could be done, and
> a third might be worthwhile:
>
Do you have some SCSI background?
If you do, then you know that there are a lot of vendor unique commands
that have a different meaning depending on thevendor and that you need to
support these commands if you do not like to stick at a rudimentary device
support level. Cdrtools have a more than 10 year history of supporting
vendor unique functions for the convenience of the users.
> [1] The restrictions are implemented in one way in the /dev/sg
> generic SCSI driver (older code), and another way in the
> general-purpose block-device driver (newer code).
>
> It would seem to make good sense to factor this code out,
> and have just a single implementation (probably based on the
> newer code, which appears to be more flexible and more
> MMC-3-friendly).
First, for a long time Linux did need root privileges in order to send
SCSI commands. The fact that newer Linux version allow to do this without
root privileges is a bug introduced by an inexperienced kernel hacker.
Instead of fixing this obvious bug, a random filter list has been introduced.
Note that the security problem in Linux is still present as the current
implementation allows the backup admin to gain root privileges.
> [2] The list of MMC-3 commands allowed for non-root write access
> in the block device driver might be expanded.
>
> [3] The list of commands might be made extensible at run time,
> possibly on a per-device basis. This might be done via the
> Linux /proc or /sys interfaces. The built-in list could be used
> in most cases, but the individual system owner could extend it
> if a particular drive needed a drive-specific command for
> full-featured operation.
Forget about all these thoughts. Linux will either equire root
privileges for cdrecord or it will allow the backup admin to gain
root privileges.
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: