Mailing List Archive: Gentoo: Dev

useless set*id binaries

Index | Next | Previous | View Threaded

vapier at gentoo

Jan 27, 2012, 4:14 PM

Post #1 of 14 (620 views)
Permalink

*useless setid binaries**

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

Attachments:

signature.asc (0.82 KB)

ssuominen at gentoo

Jan 27, 2012, 4:18 PM

Post #2 of 14 (584 views)
Permalink

*Re: useless setid binaries** [In reply to]

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)

vapier at gentoo

Jan 27, 2012, 4:41 PM

Post #3 of 14 (584 views)
Permalink

*Re: useless setid binaries** [In reply to]

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

Attachments:

signature.asc (0.82 KB)

ssuominen at gentoo

Jan 27, 2012, 5:07 PM

Post #4 of 14 (592 views)
Permalink

*Re: useless setid binaries** [In reply to]

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 [at] nul ~ $ 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 [at] nul ~ $ sudo chmod 755 /usr/bin/cdrecord
ssuominen [at] nul ~ $ 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 [at] nul ~ $ groups
wheel audio cdrom video games cdrw usb users portage
ssuominen [at] nul ~ $

chithanh at gentoo

Jan 27, 2012, 5:28 PM

Post #5 of 14 (584 views)
Permalink

*Re: useless setid binaries** [In reply to]

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

vapier at gentoo

Jan 27, 2012, 5:49 PM

Post #6 of 14 (584 views)
Permalink

*Re: useless setid binaries** [In reply to]

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

Attachments:

signature.asc (0.82 KB)

ssuominen at gentoo

Jan 27, 2012, 5:49 PM

Post #7 of 14 (588 views)
Permalink

*Re: useless setid binaries** [In reply to]

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 [at] gentoo>
+ +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)

vapier at gentoo

Jan 27, 2012, 5:54 PM

Post #8 of 14 (585 views)
Permalink

*Re: useless setid binaries** [In reply to]

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

Attachments:

signature.asc (0.82 KB)

vapier at gentoo

Jan 27, 2012, 6:14 PM

Post #9 of 14 (584 views)
Permalink

*Re: useless setid binaries** [In reply to]

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

Attachments:

signature.asc (0.82 KB)

ulm at gentoo

Jan 27, 2012, 10:28 PM

Post #10 of 14 (578 views)
Permalink

*Re: useless setid binaries** [In reply to]

>>>>> 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 [at] gentoo>
> + +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

ssuominen at gentoo

Jan 27, 2012, 11:19 PM

Post #11 of 14 (579 views)
Permalink

*Re: useless setid binaries** [In reply to]

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 [at] gentoo>
>> + +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.

ulm at gentoo

Jan 28, 2012, 12:15 AM

Post #12 of 14 (575 views)
Permalink

*Re: useless setid binaries** [In reply to]

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

mgorny at gentoo

Jan 28, 2012, 12:32 AM

Post #13 of 14 (574 views)
Permalink

*Re: useless setid binaries** [In reply to]

On Sat, 28 Jan 2012 03:07:45 +0200
Samuli Suominen <ssuominen [at] gentoo> 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 [at] nul ~ $ cdrecord -scanbus

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

--
Best regards,
Michał Górny

Attachments:

signature.asc (0.31 KB)

ssuominen at gentoo

Jan 28, 2012, 12:35 AM

Post #14 of 14 (574 views)
Permalink

*Re: useless setid binaries** [In reply to]

On 01/28/2012 10:32 AM, Michał Górny wrote:
> On Sat, 28 Jan 2012 03:07:45 +0200
> Samuli Suominen<ssuominen [at] gentoo> 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 [at] nul ~ $ 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.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads