[gentoo-dev] useless set*id binaries

[gentoo-dev] useless set*id binaries

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

hmm, i wonder why mount.nfs is set*id.  if we require everyone to use `mount`, 
there's no need for `mount.nfs` to be set*id.  someone want to point out 
something obvious that i'm missing before i adjust the nfs-utils package ?

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 02:14 AM, Mike Frysinger wrote:
> hmm, i wonder why mount.nfs is set*id.  if we require everyone to use `mount`,
> there's no need for `mount.nfs` to be set*id.  someone want to point out
> something obvious that i'm missing before i adjust the nfs-utils package ?
>
> 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

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)

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 894 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

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 ~ $

Re: [gentoo-dev] useless set*id binaries

[Chí-Thanh Christopher Nguyễn]

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

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2101 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

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)

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1144 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1134 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] useless set*id binaries

[Ulrich Mueller]

>>>>> 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

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

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.

Re: [gentoo-dev] useless set*id binaries

[Ulrich Mueller]

>>>>> 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.

Re: [gentoo-dev] useless set*id binaries

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Sat, 28 Jan 2012 03:07:45 +0200
Samuli Suominen <ssuominen@gentoo.org> 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:
> 
> ssuominen@null ~ $ cdrecord -scanbus

Does user actually need to be able to do this? Doesn't passing dev=...
directly work?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 10:32 AM, Michał Górny wrote:
> On Sat, 28 Jan 2012 03:07:45 +0200
> Samuli Suominen<ssuominen@gentoo.org>  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:
>>
>> ssuominen@null ~ $ cdrecord -scanbus
>
> Does user actually need to be able to do this? Doesn't passing dev=...
> directly work?
>

It will work if you specify it by hand. But how do you know without 
using -scanbus what to specify?

Also, burning frontends, such as xfburn, rely on this functionality to 
automatically find the burner when USE="udev" is disabled.

And if I don't remember wrong, k3b also uses it as fallback method.