FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-27-2012, 11:41 PM
Mike Frysinger
 
Default useless set*id binaries

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
> On 01/28/2012 02:14 AM, Mike Frysinger wrote:
> > along these lines, why is cdrtools set*id ? if we have a "cdrom" group,
> > and we assign our cdroms/dvdroms to that group, then we already have
> > access control in place and can skip the set*id.
>
> cdrtools can't probe the drives without the binary being setuid, or the
> user belonging to the 'disk' group (and even that is not enough in some
> cases if the permissions vary)

the drives are owned by the "cdrom" group and have group +rw. so if the user
is in the "cdrom" group, why can't they probe the drives ?

"disk" owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw---- 1 root disk 21, 0 Jan 6 23:07 /dev/sg0
crw-rw---- 1 root cdrom 21, 6 Jan 6 23:07 /dev/sg6
brw-rw---- 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike
 
Old 01-28-2012, 12:07 AM
Samuli Suominen
 
Default useless set*id binaries

On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ? if we have a "cdrom" group,
and we assign our cdroms/dvdroms to that group, then we already have
access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid, or the
user belonging to the 'disk' group (and even that is not enough in some
cases if the permissions vary)


the drives are owned by the "cdrom" group and have group +rw. so if the user
is in the "cdrom" group, why can't they probe the drives ?

"disk" owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw---- 1 root disk 21, 0 Jan 6 23:07 /dev/sg0
crw-rw---- 1 root cdrom 21, 6 Jan 6 23:07 /dev/sg6
brw-rw---- 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it probes
per bus, iirc


you can try it easily yourself:

ssuominen@null ~ $ cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright
(C) 1995-2011 Joerg Schilling

Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) 'ATA ' 'WDC WD5000AADS-0' '01.0' Disk
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0 100) 'ATA ' 'ST31000333AS ' 'SD25' Disk
1,1,0 101) 'TSSTcorp' 'CDDVDW SH-S223C ' 'SB06' Removable CD-ROM
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) *
scsibus4:
4,0,0 400) 'HUAWEI ' 'Mass Storage ' '2.31' Removable CD-ROM
4,1,0 401) *
4,2,0 402) *
4,3,0 403) *
4,4,0 404) *
4,5,0 405) *
4,6,0 406) *
4,7,0 407) *
scsibus5:
5,0,0 500) 'HUAWEI ' 'TF CARD Storage ' ' ' Removable Disk
5,1,0 501) *
5,2,0 502) *
5,3,0 503) *
5,4,0 504) *
5,5,0 505) *
5,6,0 506) *
5,7,0 507) *
ssuominen@null ~ $ sudo chmod 755 /usr/bin/cdrecord
ssuominen@null ~ $ cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright
(C) 1995-2011 Joerg Schilling
cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open or use
SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you
are root.

cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
ssuominen@null ~ $ groups
wheel audio cdrom video games cdrw usb users portage
ssuominen@null ~ $
 
Old 01-28-2012, 12:28 AM
Chí-Thanh Christopher Nguyễn
 
Default useless set*id binaries

Mike Frysinger schrieb:
> along these lines, why is cdrtools set*id ? if we have a "cdrom" group, and
> we assign our cdroms/dvdroms to that group, then we already have access
> control in place and can skip the set*id.
> -mike
From the manpage, "In order to be able to use the SCSI transport
subsystem of the OS, run at highest priority and lock itself into core
cdrecord either needs to be run as root, needs to be installed suid root
or must be called via RBACs pfexec mechanism."

I guess with the advent of burnfree technology, the priority and locking
into memory have become less important.

The cdrom group will give access to /dev/sr* but not the associated /dev/sg*


Best regards,
Ch*-Thanh Christopher Nguyễn
 
Old 01-28-2012, 12:49 AM
Mike Frysinger
 
Default useless set*id binaries

On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:
> On 01/28/2012 02:41 AM, Mike Frysinger wrote:
> > On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
> >> On 01/28/2012 02:14 AM, Mike Frysinger wrote:
> >>> along these lines, why is cdrtools set*id ? if we have a "cdrom"
> >>> group, and we assign our cdroms/dvdroms to that group, then we already
> >>> have access control in place and can skip the set*id.
> >>
> >> cdrtools can't probe the drives without the binary being setuid, or the
> >> user belonging to the 'disk' group (and even that is not enough in some
> >> cases if the permissions vary)
> >
> > the drives are owned by the "cdrom" group and have group +rw. so if the
> > user is in the "cdrom" group, why can't they probe the drives ?
> >
> > "disk" owns the non-removable hard drives.
> >
> > $ ls -l /dev/sr0 /dev/sg0 /dev/sg6
> > crw-rw---- 1 root disk 21, 0 Jan 6 23:07 /dev/sg0
> > crw-rw---- 1 root cdrom 21, 6 Jan 6 23:07 /dev/sg6
> > brw-rw---- 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
> > -mike
>
> i dont know why, but it does probe also non-removable disks... it probes
> per bus, iirc
>
> you can try it easily yourself:

this is a failure in cdrecord (not that surprising). it aborts after the first
EACCES it gets on /dev/sg# instead of continuing on. granting set*id to a
binary because they can't be bothered to try the next device is dumb.

$ sudo mv /dev/sg[0-5] ~/
$ sudo chmod 755 /usr/bin/cdrecord
$ cdrecord -scanbus

Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright (C)
1995-2011 Joerg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
Using libscg transport code version 'schily-scsi-linux-sg.c-1.95'
Driveropts: 'burnfree'
SCSI buffer size: 32768
scsibus7:
7,0,0 700) 'TSSTcorp' 'CDDVDW SH-S222L ' 'SB03' Removable CD-ROM
7,1,0 701) *
7,2,0 702) *
7,3,0 703) *
7,4,0 704) *
7,5,0 705) *
7,6,0 706) *
7,7,0 707) *
-mike
 
Old 01-28-2012, 12:49 AM
Samuli Suominen
 
Default useless set*id binaries

On 01/28/2012 03:49 AM, Mike Frysinger wrote:

On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:

On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ? if we have a "cdrom"
group, and we assign our cdroms/dvdroms to that group, then we already
have access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid, or the
user belonging to the 'disk' group (and even that is not enough in some
cases if the permissions vary)


the drives are owned by the "cdrom" group and have group +rw. so if the
user is in the "cdrom" group, why can't they probe the drives ?

"disk" owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw---- 1 root disk 21, 0 Jan 6 23:07 /dev/sg0
crw-rw---- 1 root cdrom 21, 6 Jan 6 23:07 /dev/sg6
brw-rw---- 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it probes
per bus, iirc

you can try it easily yourself:


this is a failure in cdrecord (not that surprising). it aborts after the first
EACCES it gets on /dev/sg# instead of continuing on. granting set*id to a
binary because they can't be bothered to try the next device is dumb.

$ sudo mv /dev/sg[0-5] ~/
$ sudo chmod 755 /usr/bin/cdrecord
$ cdrecord -scanbus

Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright (C)
1995-2011 Joerg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
Using libscg transport code version 'schily-scsi-linux-sg.c-1.95'
Driveropts: 'burnfree'
SCSI buffer size: 32768
scsibus7:
7,0,0 700) 'TSSTcorp' 'CDDVDW SH-S222L ' 'SB03' Removable CD-ROM
7,1,0 701) *
7,2,0 702) *
7,3,0 703) *
7,4,0 704) *
7,5,0 705) *
7,6,0 706) *
7,7,0 707) *
-mike


and people have multiple times tried to convince the cdrtools author to
change this, but without success.

the author can be, well, ...

i've improved the situation _a bit_:

+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+ 28 Jan 2012; Samuli Suominen <ssuominen@gentoo.org>
+ +cdrtools-3.01_alpha06-r1.ebuild:
+ Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
disk for

+ udev users (note: tested with cdrecord -scanbus)
 
Old 01-28-2012, 12:54 AM
Mike Frysinger
 
Default useless set*id binaries

On Friday 27 January 2012 20:28:04 Ch*-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> > along these lines, why is cdrtools set*id ? if we have a "cdrom" group,
> > and we assign our cdroms/dvdroms to that group, then we already have
> > access control in place and can skip the set*id.
>
> From the manpage, "In order to be able to use the SCSI transport
> subsystem of the OS, run at highest priority and lock itself into core
> cdrecord either needs to be run as root, needs to be installed suid root
> or must be called via RBACs pfexec mechanism."
>
> I guess with the advent of burnfree technology, the priority and locking
> into memory have become less important.

yeah, i would think if your system is loaded enough for this to be an issue,
it's going to be an issue anyways. but i'd image mlock/rtprio could be
enabled via pam and security/limits.conf for the cdrom group.

> The cdrom group will give access to /dev/sr* but not the associated
> /dev/sg*

yes, it does:
$ find -L /dev/* -maxdepth 0 -gid 19
/dev/cdrom
/dev/cdrw
/dev/dvd
/dev/dvdrw
/dev/scd0
/dev/sg6
/dev/sr0
-mike
 
Old 01-28-2012, 01:14 AM
Mike Frysinger
 
Default useless set*id binaries

On Friday 27 January 2012 20:49:49 Samuli Suominen wrote:
> and people have multiple times tried to convince the cdrtools author to
> change this, but without success.
> the author can be, well, ...

sure, i'm not expecting him to be anything resembling reasonable. but if we
can reduce set*id impact by default and that means carrying a custom patch, i
think that's OK.

i thought we used to have set*id USE flags, but maybe all the packages with it
have migrated away.

my proposal would be to add a patch to ignore EACCES just like it already does
for ENOENT. then add a setuid USE flag that'd give the behavior we have today
(disabled by default) for the binaries that do writing. the ones that only
read have no excuse for needing setuid. then if the user has built with USE=-
setuid, we elog a message like:
you've built with USE=-setuid. that means in order to access
your discs, you need to add yourself to the cdrom group.
if your burning does not go well, you can try adding the cdrom
group to limits.conf with rtprio/mlock access like so:
<snippets for people to copy & paste>
-mike
 
Old 01-28-2012, 05:28 AM
Ulrich Mueller
 
Default useless set*id binaries

>>>>> On Sat, 28 Jan 2012, Samuli Suominen wrote:

> i've improved the situation _a bit_:

> +*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
> +
> + 28 Jan 2012; Samuli Suominen <ssuominen@gentoo.org>
> + +cdrtools-3.01_alpha06-r1.ebuild:
> + Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
> disk for
> + udev users (note: tested with cdrecord -scanbus)

This is definitely not an improvement and should be reverted. The suid
root is also needed to elevate cdrecord's scheduling priority.

And is this such an urgent matter that there wasn't time to file a
proper bug? Or have you discussed this change with the package's
maintainer?

if has_version sys-fs/udev; then
fowners root:disk /usr/bin/{cdda2wav,cdrecord,readcd} /usr/sbin/rscsi
fperms u-s,g+s /usr/bin/{cdda2wav,cdrecord,readcd} /usr/sbin/rscsi
fi

Automagic dependency on udev in src_install? Oh my.

Ulrich
 
Old 01-28-2012, 06:19 AM
Samuli Suominen
 
Default useless set*id binaries

On 01/28/2012 08:28 AM, Ulrich Mueller wrote:

On Sat, 28 Jan 2012, Samuli Suominen wrote:



i've improved the situation _a bit_:



+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+ 28 Jan 2012; Samuli Suominen<ssuominen@gentoo.org>
+ +cdrtools-3.01_alpha06-r1.ebuild:
+ Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
disk for
+ udev users (note: tested with cdrecord -scanbus)


This is definitely not an improvement and should be reverted. The suid
root is also needed to elevate cdrecord's scheduling priority.


Missed that piece of code and reverted then. Any chance you could be
more specific?



if has_version sys-fs/udev; then
fowners root:disk /usr/bin/{cdda2wav,cdrecord,readcd} /usr/sbin/rscsi
fperms u-s,g+s /usr/bin/{cdda2wav,cdrecord,readcd} /usr/sbin/rscsi
fi

Automagic dependency on udev in src_install? Oh my.


I don't consider this as a automagic to be worried about at all.
Was bouncing back and forth with 'use kernel_linux' or 'has_version
sys-fs/udev', since wasn't sure how other devmanagers have permissions
set. But I guess this is now irrelevant since it's reverted.
 
Old 01-28-2012, 07:15 AM
Ulrich Mueller
 
Default useless set*id binaries

>>>>> On Sat, 28 Jan 2012, Samuli Suominen wrote:

>> This is definitely not an improvement and should be reverted. The
>> suid root is also needed to elevate cdrecord's scheduling priority.

> Missed that piece of code and reverted then. Any chance you could be
> more specific?

cdrecord calls mlock(2), setpriority(2), and sched_setscheduler(2) to
lock itself in memory and set realtime scheduling (and after having
done so, it of course resets its uid to non-root).

And yes, it really makes a difference on a moderately loaded machine.
(Having written data from physics experiments to thousands of
CDs/DVDs/Blurays, I think I can claim some experience here.)

With file based capabilities, one could set CAP_IPC_LOCK and
CAP_SYS_NICE instead of the suid root.
 

Thread Tools




All times are GMT. The time now is 11:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org