[gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Joerg Schilling
Hi all,

since Linux-2.6.24, fcaps support is part of the vanilla kernel.
If you also add libcap user and developer support and the commands
getcap and setcap, you will be able to install working versions for:

cdrecord, cdda2wav, readcd

without making them suid-root. 

This works with cdrtools-3.01a14 or later. Check

ftp://ftp.berlios.de/pub/cdrecord/alpha/

for the sources.

Happy hacking!

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Bruce Hill
On Fri, Apr 26, 2013 at 06:18:13PM +0200, Joerg Schilling wrote:
 Hi all,
 
 since Linux-2.6.24, fcaps support is part of the vanilla kernel.
 If you also add libcap user and developer support and the commands
 getcap and setcap, you will be able to install working versions for:
 
   cdrecord, cdda2wav, readcd
 
 without making them suid-root. 
 
 This works with cdrtools-3.01a14 or later. Check
 
   ftp://ftp.berlios.de/pub/cdrecord/alpha/
 
 for the sources.
 
 Happy hacking!
 
 Jörg

Thanks, Jorg
-- 
Happy Penguin Computers   ')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting



Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Daniel Pielmeier
Joerg Schilling schrieb am 26.04.2013 18:18:
 Hi all,
 
 since Linux-2.6.24, fcaps support is part of the vanilla kernel.
 If you also add libcap user and developer support and the commands
 getcap and setcap, you will be able to install working versions for:
 
   cdrecord, cdda2wav, readcd
 
 without making them suid-root. 
 
 This works with cdrtools-3.01a14 or later. Check
 
   ftp://ftp.berlios.de/pub/cdrecord/alpha/
 
 for the sources.
 
 Happy hacking!
 
 Jörg
 

Thanks Jörg,

I have read the release notes for alpha14 and prepared an ebuild
which automatically applies the required capabilities if the filecaps
USE flag is set.

Is there any chance to make this a configurable option, so it is
possible to disable file capabilities even if libcap is installed?

-- 
Regards
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Joerg Schilling
Daniel Pielmeier bil...@gentoo.org wrote:

  without making them suid-root. 
  
  This works with cdrtools-3.01a14 or later. Check
  
  ftp://ftp.berlios.de/pub/cdrecord/alpha/

 Thanks Jörg,

 I have read the release notes for alpha14 and prepared an ebuild
 which automatically applies the required capabilities if the filecaps
 USE flag is set.

 Is there any chance to make this a configurable option, so it is
 possible to disable file capabilities even if libcap is installed?

If you install cdrecord/cdda2wav/readcd suid-root instead of applying the
facps privileges, cdrtools will automatically behave as before. Is this 
sufficient?

Note that if cdrtools was compiled on a machine with libcap installed, it needs 
libcap to run.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Daniel Pielmeier
Joerg Schilling schrieb am 26.04.2013 19:07:
 Daniel Pielmeier bil...@gentoo.org wrote:
 
 without making them suid-root. 

 This works with cdrtools-3.01a14 or later. Check

 ftp://ftp.berlios.de/pub/cdrecord/alpha/
 
 Thanks Jörg,

 I have read the release notes for alpha14 and prepared an ebuild
 which automatically applies the required capabilities if the filecaps
 USE flag is set.

 Is there any chance to make this a configurable option, so it is
 possible to disable file capabilities even if libcap is installed?
 
 If you install cdrecord/cdda2wav/readcd suid-root instead of applying the
 facps privileges, cdrtools will automatically behave as before. Is this 
 sufficient?
 
 Note that if cdrtools was compiled on a machine with libcap installed, it 
 needs 
 libcap to run.
 
 Jörg
 

Actually it is the linkage against libcap what I am concerned of.

Imagine the following scenario. Libcap is not present on the system.
Then package X which requires libcap is installed and the package
manager who knows this installs libcap as a dependency. Then package Y
is installed which unconditionally links against libcap. The package
manager is unaware of this and does not know about the dependency. Now
package X is uninstalled and the package manager removes libcap because
he thinks nothing on the system needs it anymore. Now package Y will
stop working because libcap is not there anymore. If it is possible to
conditionally link against libcap such issues could be avoided. Libcap
will not be uninstalled if the dependency is known. Additionally it is
possible to have libcap installed and not link cdrtools against it.

-- 
Regards
Daniel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Joerg Schilling
Daniel Pielmeier bil...@gentoo.org wrote:

 Actually it is the linkage against libcap what I am concerned of.

This is what I call a security risk with the current concepts of some linux 
systems. See Announcement file for more

 Imagine the following scenario. Libcap is not present on the system.
 Then package X which requires libcap is installed and the package
 manager who knows this installs libcap as a dependency. Then package Y
 is installed which unconditionally links against libcap. The package
 manager is unaware of this and does not know about the dependency. Now
 package X is uninstalled and the package manager removes libcap because
 he thinks nothing on the system needs it anymore. Now package Y will
 stop working because libcap is not there anymore. If it is possible to
 conditionally link against libcap such issues could be avoided. Libcap
 will not be uninstalled if the dependency is known. Additionally it is
 possible to have libcap installed and not link cdrtools against it.

On Solaris, you cannot remove files that are part of the basic kernel features.

Privileges on Solaris are a basic kernel feature and part of the basic 
security concept, so you cannot remove this on most Linux distros, it seems 
that you can.

I am concerned about a different scenario:

Imagine, you compile cdrtools without libcap and later install the support for 
the OS. Now you decide to use setcap to make cdrecord work. Cdrecord will 
really work this way, but you opened a security hole as this cdrecord now is 
not privileges aware and thus cannot even detect that it is running with more 
than basic privileges. Such a cdrecord installation will happyly write any 
local file for any local user to CD.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Daniel Pielmeier
Joerg Schilling schrieb am 26.04.2013 20:31:
 Daniel Pielmeier bil...@gentoo.org wrote:
 
 Actually it is the linkage against libcap what I am concerned of.
 
 This is what I call a security risk with the current concepts of some linux 
 systems. See Announcement file for more
 
 Imagine the following scenario. Libcap is not present on the system.
 Then package X which requires libcap is installed and the package
 manager who knows this installs libcap as a dependency. Then package Y
 is installed which unconditionally links against libcap. The package
 manager is unaware of this and does not know about the dependency. Now
 package X is uninstalled and the package manager removes libcap because
 he thinks nothing on the system needs it anymore. Now package Y will
 stop working because libcap is not there anymore. If it is possible to
 conditionally link against libcap such issues could be avoided. Libcap
 will not be uninstalled if the dependency is known. Additionally it is
 possible to have libcap installed and not link cdrtools against it.
 
 On Solaris, you cannot remove files that are part of the basic kernel 
 features.
 
 Privileges on Solaris are a basic kernel feature and part of the basic 
 security concept, so you cannot remove this on most Linux distros, it 
 seems 
 that you can.
 
 I am concerned about a different scenario:
 
 Imagine, you compile cdrtools without libcap and later install the support 
 for 
 the OS. Now you decide to use setcap to make cdrecord work. Cdrecord will 
 really work this way, but you opened a security hole as this cdrecord now is 
 not privileges aware and thus cannot even detect that it is running with more 
 than basic privileges. Such a cdrecord installation will happyly write any 
 local file for any local user to CD.
 
 Jörg
 

If you add an option to make conditional linkage against libcap possible
there are only two possible scenarios. cdrtools links against libcap and
the capabilities are set or it doesn't link against libcap and cdrtools
are installed suid root without capabilities.

Everything is done in the ebuild and the user does not need to mess with
setcap. It is controlled by the package manager and the linkage and
capability setting are tied together at installation time.

Just adding an option similar to the one for the ACLs would make my live
a lot easier. Just enable it by default and make it possible to switch
it off.

-- 
Regards
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] Cdrtools installation without suid root

2013-04-26 Thread Joerg Schilling
Daniel Pielmeier bil...@gentoo.org wrote:

  I am concerned about a different scenario:
  
  Imagine, you compile cdrtools without libcap and later install the support 
  for 
  the OS. Now you decide to use setcap to make cdrecord work. Cdrecord will 
  really work this way, but you opened a security hole as this cdrecord now 
  is 
  not privileges aware and thus cannot even detect that it is running with 
  more 
  than basic privileges. Such a cdrecord installation will happyly write any 
  local file for any local user to CD.
  
  Jörg
  

 If you add an option to make conditional linkage against libcap possible
 there are only two possible scenarios. cdrtools links against libcap and
 the capabilities are set or it doesn't link against libcap and cdrtools
 are installed suid root without capabilities.

 Everything is done in the ebuild and the user does not need to mess with
 setcap. It is controlled by the package manager and the linkage and
 capability setting are tied together at installation time.

 Just adding an option similar to the one for the ACLs would make my live
 a lot easier. Just enable it by default and make it possible to switch
 it off.

I am not shure whether there is a missunderstanding.

You could have an installation without libcap and without setcap/getcap where 
cdrecord still has active file capabilities. Nobody could check why, but 
cdrecord would be able to write any local file to CD on such a system.

The only problem I see is that you are able to remove important software on a 
Linux installation while the kernel still supports the feature by default.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily