Hello,

I've done some trials as root to write cdroms, and that works fine.
In order to do that as ordinary user, I've set the right access to
the device as :

root@lebrac:~# ls -l /dev/scd0
brw-rw---- 1 root cdburn 11, 0 1994-07-18 18:06 /dev/scd0

and added the potential users in the new group cdburn.
But when I try the operation with the option -dummy, I get some warnings
that I didn't get when I was root. Is it possible to correct that ?
And is it really a risk ?
/usr/bin/cdrecord is not suid-root, I thought it was more secure to change
the rights of the device that those of the executable.

Some opinions ?

gv@lebrac:~$ cdrecord -v -dummy speed=4 dev=1,1,0 image_iso
Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling
TOC Type: 1 = CD-ROM
cdrecord: Operation not permitted. WARNING: Cannot do mlockall(2).
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().
cdrecord: WARNING: This causes a high risk for buffer underruns.
scsidev: '1,1,0'
scsibus: 1 target: 1 lun: 0
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.7'
atapi: 0
Device type : Removable CD-ROM
Version : 2
Response Format: 2
Capabilities :
Vendor_info : 'YAMAHA '
Identifikation : 'CRW4260 '
Revision : '1.0h'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags : MMC SWABAUDIO
Supported modes: TAO PACKET SAO RAW/R96R
Drive buf size : 1176000 = 1148 KB
FIFO size : 4194304 = 4096 KB
Track 01: data 562 MB
Total size: 645 MB (63:59.60) = 287970 sectors
Lout start: 646 MB (64:01/45) = 287970 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 4
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, high Beta category (A+) (3)
ATIP start of lead in: -11077 (97:34/23)
ATIP start of lead out: 359848 (79:59/73)
Disk type: Long strategy type (Cyanine, AZO or similar)
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
Blocks total: 359848 Blocks current: 359848 Blocks remaining: 71878
cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().
cdrecord: WARNING: This causes a high risk for buffer underruns.
Starting to write CD/DVD at speed 4 in dummy TAO mode for single session.
Last chance to quit, starting dummy write 0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
Starting new track at sector: 0
Track 01: 20 of 562 MB written (fifo 100%) [buf 98%] 4.0x.


--
^^ Gauthier
(_____/°°-ç
| \_`-"
)/@mmm||
\nn \nn FOE-Belgium : http://www.amisdelaterre.be

> I've done some trials as root to write cdroms, and that works fine.
> In order to do that as ordinary user, I've set the right access to
> the device as :
>
> root@lebrac:~# ls -l /dev/scd0
> brw-rw---- 1 root cdburn 11, 0 1994-07-18 18:06 /dev/scd0
>
> and added the potential users in the new group cdburn.
> But when I try the operation with the option -dummy, I get some warnings
> that I didn't get when I was root. Is it possible to correct that ?
> And is it really a risk ?
> /usr/bin/cdrecord is not suid-root, I thought it was more secure to change
> the rights of the device that those of the executable.

It is more secure, but the main reason the programs want suid-root is memory
and processor, not dev access. cdrecord needs to be able to guarantee that
the data will be fed to the cd burner continuously - if it's not running as
root, other programs can steal its processor time and force it to swap out
buffers from ram, leading to you making a coaster. I'd recommend using suid
root.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, MikeyD dared to utter,
> I'd recommend using suid
> root.

Yeah, and while you're at it change the permissions to 750. You can add
a new group, and chgrp this file to that group. Now only put local
users in that group. I'm not currently aware of any exploits for
cdrecord, but who knows? It never hurts to be a little extra secure
sometimes.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAdHlxL3KiNGOqr6ERAmUVAJ0bRkWlKiIqQ6kfXZV+5C +Fe/whnwCgqOAl
m7Jy9B2iWFeDYbmQmgklStw=
=P+Jw
-----END PGP SIGNATURE-----

MikeyD wrote:
> It is more secure, but the main reason the programs want suid-root is memory
> and processor, not dev access. cdrecord needs to be able to guarantee that
> the data will be fed to the cd burner continuously - if it's not running as
> root, other programs can steal its processor time and force it to swap out
> buffers from ram, leading to you making a coaster. I'd recommend using suid
> root.

or better yet, sudo. that way you can determine which users get to run
cdrecord as root.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

On Wed, 07 Apr 2004 20:06:33 +0000, Gauthier wrote:
> root@lebrac:~# ls -l /dev/scd0
> brw-rw---- 1 root cdburn 11, 0 1994-07-18 18:06 /dev/scd0
> [snip]
> Some opinions ?

1. Not an opinion, a fact: you are looking at the wrong device node.
The block-major-11 ones are for CD *reading* only. Depending (I think)
on how many SCSI devices are on your system and the order in which
their host adapter drivers load, and then their order on the SCSI bus,
your writing will be done on one of the /dev/sg* devices. If this is
your only SCSI device (ide-scsi driver) your burning device is sg0.

2. Opinion: I do it the way Alan said, "chmod 4750 /usr/bin/cdrecord",
and any other necessary binaries (readcd? cdparanoia?) as well. Look at
your own warning message about mlockall.

3. xcdroast, found in /extra, offers a very easy way to manage the
permissions of CD writing.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

Many thanks to all
--
^^
(_____/°°-ç Gauthier
| \_`-"
)/@mmm||
\nn \nn
FOE-Belgium : http://www.amisdelaterre.be

On Wed, 07 Apr 2004 20:06:33 +0000, Gauthier wrote:

> Hello,

Hello, this reply my very well be moot. As you probably have it working
fine by now ...

> I've done some trials as root to write cdroms, and that works fine.
> In order to do that as ordinary user, I've set the right access to
> the device as :
>
> root@lebrac:~# ls -l /dev/scd0
> brw-rw---- 1 root cdburn 11, 0 1994-07-18 18:06 /dev/scd0
>
> and added the potential users in the new group cdburn.

This is a dangerous thing to do. Unless you trust all users part of the
"cdburn" group to mess about SCSI commands: "chmod g-w" that.

man cdrecord <- look for "chmod" in there

> But when I try the operation with the option -dummy, I get some warnings
> that I didn't get when I was root. Is it possible to correct that ?

As others have pointed out: yes, there is.
Change the access right to suid, or use a wrapper (and suid that instead).

> And is it really a risk ?

Yes. It increses the chance of a buffer under run (mis burn).
But then others have pointed that out already as well ...

> /usr/bin/cdrecord is not suid-root, I thought it was more secure to change
> the rights of the device that those of the executable.

From reading the manpage, i don't think it is ...

> Some opinions ?

According to the author(s), "cdrecord", "readcd", et all, should be
set-uid save. Hence, you could:

chgrp cdburn `which cdrecord`
chmod 4710 `which cdrecord`

Not giveing out read permission to anyone but the owner (root) prevents
users from trying to debug / decompile . To further obscure it, recompile
with as much optimization as you can get away with, and:

chattr +i `which cdrecord`

(Good idee might be to just mount /usr read-only BTW.)

However, (as with anything that sits on a priv boundary) all it takes is
one little mistake or oversight. And seeing how much code we're looking at
- and the enormous amount of options supported by it - auditing might be
a tedious undertaking. So a wrapper my be in order (provided you _realy_
distrust your users ... :-))

As others have pointed out, short of writeing your own wrapper try "sudo".
As it does some neat logging, and allows for filter rules on what options
to "cdrecord" users can provide, from which hosts they should be
connecting, etc. "man sudo" , "man sudoers" , "man visudo" .

Of cource "sudo" itself is a securety liability as well (as it has to be
suid to root) and terefor the above security/obscurity goes for it also:

groupadd sudoers
grpconv
mount -o remount,rw /usr
chgrp sudoers `which sudo`
chmod 4710 `which sudo`
chattr +i `which sudo`
mount -o remount,ro /usr

And put any users that need access through it (to some functionality) in
the "sudoers" group. Again to obscure debugging some more, you can
recompile the "sudo" binary optimised (or better yet, patch gcc with
ProPolice, and/or use hardware with an arch other then x86...)

The whole "linux capability" thing seems interesting (allowing one to
restrict which system calls a program can make), i have not yet looked
much into that however:
http://users.piuha.net/martti/comp/s...slackware.html

(Note, there are other kernel patches the paranoit might want to look
into as well, such as: LIDS, SE, PAX, OpenWall, and what not.)

Up to you, what you consider secure enough, have fun.

--
-Menno.

On Fri, 09 Apr 2004 16:29:09 +0000, Menno Duursma wrote:

[ Big snip. ]

> The whole "linux capability" thing seems interesting (allowing one to
> restrict which system calls a program can make), i have not yet looked
> much into that however:
> http://users.piuha.net/martti/comp/s...slackware.html

Oops, wrong URL :-( sorry.

For anyone interested, try this one (and the links on that) instead:
http://www.olafdietsche.de/linux/capability/

( And, have a read through: less /usr/include/linux/capability.h ).

--
-Menno.

Joost Kremers <joostkremers@yahoo.com> wrote:
>
> or better yet, sudo. that way you can determine which users get to run
> cdrecord as root.
>

Plus, instead of sudo'ing cdrecord, you can sudo a script that only
lets a normal user do very specific things (say, accepts a directory
and burns that to a disk).

- Kurt