Re: [Cooker] Strange permissions of mkisofs
Alexander Skwar [EMAIL PROTECTED] writes: [askwar@teich RPM]$ which mkisofs /usr/bin/mkisofs [askwar@teich RPM]$ ls -la $(which mkisofs) -rwxr-s---2 root cdwriter 323036 Mr 2 12:25 /usr/bin/mkisofs* [askwar@teich RPM]$ rpm -qf $(which mkisofs ) mkisofs-1.13-5mdk That is, why is mkisofs not executable by anyone? it's executable by everyone in cdwriter group. Whether normal users are in this group vary with security level. What harm can possibly be done by running mkisofs? see later And also, what is it set gid for? to enable some users and not some others to use it by specifying who is in this group. and to let these users having access to the required devices (/dev/sg*, /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel writers]).. As for cdrecord, it MUST be SUID root because it locks itself in memory which can only be done with root rights (see "man cdrecord"). cdda2wav has some real time features and to support them it is SUID root, too. So we make all these utilities be root.cdwriter owned and use goup membership to offer security. And last, why is it owned by group cdwriter, and not group root, like about anything else? root suid (or guid) binaries are very, very _bad_. better giving accesse to a sub-system than to the whole system in case of security hole.
Re: [Cooker] Strange permissions of mkisofs
Thierry Vignaud wrote: Essantially making mkisofs a+rx is no harm whatsoever. I create .iso's the get written using another machine, the machine I create the .iso's on does not have a CD writer, and I would prefer to be able to create .iso's as me, they still end up group owned by cdwriter. Alexander Skwar [EMAIL PROTECTED] writes: [askwar@teich RPM]$ which mkisofs /usr/bin/mkisofs [askwar@teich RPM]$ ls -la $(which mkisofs) -rwxr-s---2 root cdwriter 323036 Mr 2 12:25 /usr/bin/mkisofs* [askwar@teich RPM]$ rpm -qf $(which mkisofs ) mkisofs-1.13-5mdk That is, why is mkisofs not executable by anyone? it's executable by everyone in cdwriter group. Whether normal users are in this group vary with security level. What harm can possibly be done by running mkisofs? see later And also, what is it set gid for? to enable some users and not some others to use it by specifying who is in this group. and to let these users having access to the required devices (/dev/sg*, /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel writers]).. As for cdrecord, it MUST be SUID root because it locks itself in memory which can only be done with root rights (see "man cdrecord"). cdda2wav has some real time features and to support them it is SUID root, too. So we make all these utilities be root.cdwriter owned and use goup membership to offer security. And last, why is it owned by group cdwriter, and not group root, like about anything else? root suid (or guid) binaries are very, very _bad_. better giving accesse to a sub-system than to the whole system in case of security hole. -- John Allen, Email: mailto:[EMAIL PROTECTED] Orbiscom Ltd,Web:http://www.orbiscom.com/ 3 Sandyford Park,Direct: +353-1-2178610 Sandyford Industrial Estate, Office: +353-86-2315986 Dublin 18. Fax:+353-1-2945119 ** The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This message and any attachments have been scanned for viruses. Orbiscom Ltd. will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. www.Orbiscom.com **
Re: [Cooker] Strange permissions of mkisofs
On 5 Apr 2001, Thierry Vignaud wrote: That is, why is mkisofs not executable by anyone? it's executable by everyone in cdwriter group. Whether normal users are in this group vary with security level. What harm can possibly be done by running mkisofs? see later And also, what is it set gid for? to enable some users and not some others to use it by specifying who is in this group. and to let these users having access to the required devices (/dev/sg*, /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel writers]).. But the point is that you don't need access to the devices when you build the ISO image, only when you actually burn the CD. mkisofs should be: -rwxr-xr-xroot root /usr/bin/mkisofs i.e. not set-gid or set-uid, just a normal binary. As for cdrecord, it MUST be SUID root because it locks itself in memory which can only be done with root rights (see "man cdrecord"). cdda2wav has some real time features and to support them it is SUID root, too. So we make all these utilities be root.cdwriter owned and use goup membership to offer security. But mkisofs doesn't require any privileges to run (unlike cdrecord, cdda2wav etc.), so it should be just a normal binary. Michael
Re: [Cooker] Strange permissions of mkisofs
John Allen [EMAIL PROTECTED] writes: Essantially making mkisofs a+rx is no harm whatsoever. I create .iso's the get written using another machine, the machine I create the .iso's on does not have a CD writer, and I would prefer to be able to create .iso's as me, they still end up group owned by cdwriter. nop. Mkisofs may need to read previous sessions in multi-session mode, which requires to be suid root. sorry :-(
Re: [Cooker] Strange permissions of mkisofs
Thierry Vignaud wrote: John Allen [EMAIL PROTECTED] writes: Essantially making mkisofs a+rx is no harm whatsoever. I create .iso's the get written using another machine, the machine I create the .iso's on does not have a CD writer, and I would prefer to be able to create .iso's as me, they still end up group owned by cdwriter. nop. Mkisofs may need to read previous sessions in multi-session mode, which requires to be suid root. sorry :-( Correct me if I'm wrong, but mkisofs reads previous sessions either from a device, or a file. It would only be required to be suid root if the source device or file was owner/group root, and not readable by anybody else (very unlikely, and very easily fixed) -- John Allen, Email: mailto:[EMAIL PROTECTED] Orbiscom Ltd,Web:http://www.orbiscom.com/ 3 Sandyford Park,Direct: +353-1-2178610 Sandyford Industrial Estate, Office: +353-86-2315986 Dublin 18. Fax:+353-1-2945119 ** The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This message and any attachments have been scanned for viruses. Orbiscom Ltd. will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. www.Orbiscom.com **
Re: [Cooker] Strange permissions of mkisofs
So sprach Thierry Vignaud am Thu, Apr 05, 2001 at 06:51:31PM +0200: nop. Mkisofs may need to read previous sessions in multi-session mode, which requires to be suid root. Okay, what about installing two mkisofs? One sgid cdwriter like it already is, and one the normal 644 way? This would allow normal users to create iso images, and just on the instance when a multisession cd is to be created, they'd call this special binary. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die guenstige Art an Linux Distributionen zu kommen Uptime: 2 days 0 hours 1 minute
Re: [Cooker] Strange permissions of mkisofs
So sprach Thierry Vignaud am Thu, Apr 05, 2001 at 05:24:57PM +0200: to enable some users and not some others to use it by specifying who is in this group. and to let these users having access to the required devices (/dev/sg*, /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel writers]).. But why should not anyone be able to create an iso image? mkisofs doesn't do anything remotely harmful (besides writing an awful lot of data - but if the user has the space, why not?). mkisofs doesn't need any of the devices you've just listed. Your comment holds certainly true for cdrecord, and to some extent also for cdda2wav - but in no way for mkisofs. As for cdrecord, it MUST be SUID root because it locks itself in I don't care about cdrecord - because you are exactly right about what you write. root suid (or guid) binaries are very, very _bad_. better giving accesse to a sub-system than to the whole system in case of security hole. Yes, of course - but if a user has enough free space, he could also fill it with dd if=/dev/zero of=BANG - how is that ANY different than mkisofs? Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die guenstige Art an Linux Distributionen zu kommen Uptime: 1 day 23 hours 56 minutes
Re: [Cooker] Strange permissions of mkisofs
So sprach John Allen am Thu, Apr 05, 2001 at 04:28:48PM +0100: they still end up group owned by cdwriter. Do they actually need to be owned by group cdwriter? Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die guenstige Art an Linux Distributionen zu kommen Uptime: 2 days 0 hours 0 minutes
Re: [Cooker] Strange permissions of mkisofs
Alexander Skwar [EMAIL PROTECTED] writes: to enable some users and not some others to use it by specifying who is in this group. and to let these users having access to the required devices (/dev/sg*, /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel writers]).. But why should not anyone be able to create an iso image? mkisofs doesn't do anything remotely harmful (besides writing an awful lot of data - but if the user has the space, why not?). this was needed in the old days in order to read old sessions in multi-sessions mode. it seems not anymore mandatory. If someone want to test multi-mode ... mkisofs doesn't need any of the devices you've just listed. Your comment holds certainly true for cdrecord, and to some extent also for cdda2wav - but in no way for mkisofs. Yes it needs it. See above for multi-session mode As for cdrecord, it MUST be SUID root because it locks itself in I don't care about cdrecord - because you are exactly right about what you write. root suid (or guid) binaries are very, very _bad_. better giving accesse to a sub-system than to the whole system in case of security hole. Yes, of course - but if a user has enough free space, he could also fill it with dd if=/dev/zero of=BANG - how is that ANY different than mkisofs? i was not speaking of filling the hd. I spoke of security hole such as buffer overflow. Imagine such an overflow on cd title wich let you run a root shell ?? Better a cdburner shell than a root shell!
Re: [Cooker] Strange permissions of mkisofs
Alexander Skwar [EMAIL PROTECTED] writes: nop. Mkisofs may need to read previous sessions in multi-session mode, which requires to be suid root. Okay, what about installing two mkisofs? One sgid cdwriter like it already is, and one the normal 644 way? This would allow normal users to create iso images, and just on the instance when a multisession cd is to be created, they'd call this special binary. if we began to do this, then dead threads god will resume its holy threads such as why not provide a second glibc compiled with -g (and the same for all major libs), a kernel for K6, Athlon, P3, a glibc for PIII, ... 2 words : disk bloat :-(
Re: [Cooker] Strange permissions of mkisofs
On 5 Apr 2001, Thierry Vignaud wrote: to enable some users and not some others to use it by specifying who is in this group. and to let these users having access to the required devices (/dev/sg*, /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel writers]).. But why should not anyone be able to create an iso image? mkisofs doesn't do anything remotely harmful (besides writing an awful lot of data - but if the user has the space, why not?). this was needed in the old days in order to read old sessions in multi-sessions mode. it seems not anymore mandatory. If someone want to test multi-mode ... If the user is a member of the group that has access to the relevant devices, then won't they be able to access the devices anyway, without needing mkisofs to be set-gid? I may have missed something fundamental about unix permissions, but isn't it pointless to have something set-gid that is only executable if you are in the group anyway...? Michael
Re: [Cooker] Strange permissions of mkisofs
Yes, in this case, sgid is completely useless, since user already belongs to cdwriter group. Disabling the sgid bit is a little safer, for (hysterically) security conscious people. On Thu, 5 Apr 2001, Michael Brown wrote: On 5 Apr 2001, Thierry Vignaud wrote: this was needed in the old days in order to read old sessions in multi-sessions mode. it seems not anymore mandatory. If someone want to test multi-mode ... If the user is a member of the group that has access to the relevant devices, then won't they be able to access the devices anyway, without needing mkisofs to be set-gid? I may have missed something fundamental about unix permissions, but isn't it pointless to have something set-gid that is only executable if you are in the group anyway...?
