[gentoo-user] Cdrtools installation without suid root

[gentoo-user] Cdrtools installation without suid root

[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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@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

[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                       ^^
support@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

[Daniel Pielmeier]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Joerg Schilling]

Daniel Pielmeier <billie@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@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

[Daniel Pielmeier]

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

Joerg Schilling schrieb am 26.04.2013 19:07:
> Daniel Pielmeier <billie@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Joerg Schilling]

Daniel Pielmeier <billie@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@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

[Daniel Pielmeier]

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

Joerg Schilling schrieb am 26.04.2013 20:31:
> Daniel Pielmeier <billie@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Joerg Schilling]

Daniel Pielmeier <billie@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

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

[Nikos Chantziaras]

On 26/04/13 23:20, Joerg Schilling wrote:
>
> 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.

You are not able to remove it if something actually uses it.  If you 
remove the automagic dependency in cdrtools, you'll be giving the 
package manager the chance to do the right thing.

Automagic deps are a bad thing:

http://www.gentoo.org/proj/en/qa/automagic.xml

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

[Daniel Pielmeier]

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

Nikos Chantziaras schrieb am 27.04.2013 08:07:
> On 26/04/13 23:20, Joerg Schilling wrote:
>>
>> 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.
> 
> You are not able to remove it if something actually uses it.  If you
> remove the automagic dependency in cdrtools, you'll be giving the
> package manager the chance to do the right thing.
> 
> Automagic deps are a bad thing:
> 
> http://www.gentoo.org/proj/en/qa/automagic.xml
> 


Nikos thanks, this explains the problem better than I did.

Jörg just tell me if you consider adding such an option or not. I am
neither in the position to discuss decisions of the linux kernel team
and other software developers nor am I am willing to. I have to deal
with the situation I have here. In my opinion it is a good idea to add
such an option. If you think otherwise I am fine with it and I have to
use other means to make cdrtools compatible with Gentoo.

-- 
Regards
Daniel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Joerg Schilling]

Daniel Pielmeier <billie@gentoo.org> wrote:

> Nikos Chantziaras schrieb am 27.04.2013 08:07:
> > On 26/04/13 23:20, Joerg Schilling wrote:
> >>
> >> 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.
> > 
> > You are not able to remove it if something actually uses it.  If you
> > remove the automagic dependency in cdrtools, you'll be giving the
> > package manager the chance to do the right thing.
> > 
> > Automagic deps are a bad thing:
> > 
> > http://www.gentoo.org/proj/en/qa/automagic.xml

From the perspective of a single distro seen from today, this text may be 
right, if all the software has been written just for that single distro.

This is however not the case. We live in a universe that has plenty of distros 
and plenty of different operating systems. Good OpenSource software is written 
in a way that allows it to run on as many platforms as possible. This goal 
however is in conflict with the text in the "automagic" article. There are 
platforms that do not offer specific features, libraries or similar at all.
Portable software automagically adopts to what it available.

My software is "very" portable and for that reason is careful to always 
automagically detect what's present. 

Also, my software currently does not depend on non-basic features. If I e.g. 
start to continue with xcdroast, things may look different.

In general. I believe that it is the duty of a packetizer to care about the 
right dependencies.


> Nikos thanks, this explains the problem better than I did.
>
> Jörg just tell me if you consider adding such an option or not. I am

What option do you have in mind?

> neither in the position to discuss decisions of the linux kernel team
> and other software developers nor am I am willing to. I have to deal

What from the current problem depends on decisions from other people?

Some time ago, Linux added support for facps and for this reason, I need to
add support for fine grained privileges into cdrtools to prevent security risks.

> with the situation I have here. In my opinion it is a good idea to add
> such an option. If you think otherwise I am fine with it and I have to
> use other means to make cdrtools compatible with Gentoo.

Cdrtools is compatible with "linux", if you believe it is not compatible with 
Gentoo for some reason, it might be better to change something in Gentoo.

But please first explain what "option" you are talking about.

Jörg

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

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

[Nikos Chantziaras]

On 29/04/13 14:33, Joerg Schilling wrote:
> Daniel Pielmeier <billie@gentoo.org> wrote:
>> with the situation I have here. In my opinion it is a good idea to add
>> such an option. If you think otherwise I am fine with it and I have to
>> use other means to make cdrtools compatible with Gentoo.
>
> Cdrtools is compatible with "linux", if you believe it is not compatible with
> Gentoo for some reason, it might be better to change something in Gentoo.
>
> But please first explain what "option" you are talking about.

An option to forcibly enable and disable support.  If enabled, the build 
system assumes the library is there.  If disabled, it assumes the 
library is not there (even if it is).  If not given at all, do 
autodetection.

One thing I've learned in software development is that "the user knows 
best."  If the user has the library installed, he should still be able 
to tell you "yes, I have that lib, but I don't want you to use it", and 
vice versa.

Do not try to outsmart the user.  You're only getting in the way :-)

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

[Joerg Schilling]

Nikos Chantziaras <realnc@gmail.com> wrote:

> > But please first explain what "option" you are talking about.
>
> An option to forcibly enable and disable support.  If enabled, the build 
> system assumes the library is there.  If disabled, it assumes the 
> library is not there (even if it is).  If not given at all, do 
> autodetection.

This may be an option for things that really are optional.

Libcap however is not something optional but needed to support a basic security 
feature.

> One thing I've learned in software development is that "the user knows 
> best."  If the user has the library installed, he should still be able 
> to tell you "yes, I have that lib, but I don't want you to use it", and 
> vice versa.

As mentioned above, we are talking about a library to support basic security 
features, so the code from that library would really belong into libc. Since 
Linux now by default supports fcaps in the filesystems, cdrecord would open 
a security hole if the library was not used - without that library, cdrecord
cannot even see that is has been called with additional privileges that need
to be removed before the main code is executed.

Do you really like to go into a security risk with your eyes open?

Jörg

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

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

[Nikos Chantziaras]

On 29/04/13 16:09, Joerg Schilling wrote:
> Nikos Chantziaras <realnc@gmail.com> wrote:
>
>>> But please first explain what "option" you are talking about.
>>
>> An option to forcibly enable and disable support.  If enabled, the build
>> system assumes the library is there.  If disabled, it assumes the
>> library is not there (even if it is).  If not given at all, do
>> autodetection.
>
> This may be an option for things that really are optional.
>
> Libcap however is not something optional but needed to support a basic security
> feature.

I thought it is optional, since it was mentioned that cdrtools can be 
built and ran without it?

Unless you mean "recommended" instead of "required."  "Recommended" 
means it's still optional.


>> One thing I've learned in software development is that "the user knows
>> best."  If the user has the library installed, he should still be able
>> to tell you "yes, I have that lib, but I don't want you to use it", and
>> vice versa.
>
> As mentioned above, we are talking about a library to support basic security
> features, so the code from that library would really belong into libc. Since
> Linux now by default supports fcaps in the filesystems, cdrecord would open
> a security hole if the library was not used - without that library, cdrecord
> cannot even see that is has been called with additional privileges that need
> to be removed before the main code is executed.
>
> Do you really like to go into a security risk with your eyes open?

You don't know what my intentions are.  I might be doing testing, 
debugging, who knows what.  It's the "trying to be smarter than the 
user" thing.  The defaults of course would be to built the software in a 
sane, secure way.  Only users who know what they're doing would disable 
that, and they'd have their reasons.

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

[Joerg Schilling]

Nikos Chantziaras <realnc@gmail.com> wrote:

> > This may be an option for things that really are optional.
> >
> > Libcap however is not something optional but needed to support a basic security
> > feature.
>
> I thought it is optional, since it was mentioned that cdrtools can be 
> built and ran without it?

If you call something that is needed in order to prevent security holes 
"optional", you may call it optional.


> Unless you mean "recommended" instead of "required."  "Recommended" 
> means it's still optional.

Is something to grant security optional or required?


> > As mentioned above, we are talking about a library to support basic security
> > features, so the code from that library would really belong into libc. Since
> > Linux now by default supports fcaps in the filesystems, cdrecord would open
> > a security hole if the library was not used - without that library, cdrecord
> > cannot even see that is has been called with additional privileges that need
> > to be removed before the main code is executed.
> >
> > Do you really like to go into a security risk with your eyes open?
>
> You don't know what my intentions are.  I might be doing testing, 
> debugging, who knows what.  It's the "trying to be smarter than the 
> user" thing.  The defaults of course would be to built the software in a 
> sane, secure way.  Only users who know what they're doing would disable 
> that, and they'd have their reasons.

Would you call someone who shoots himself into the foot "smart"?

Recent Linux kernels support fcaps in the filesystems and "somebody" evil, who 
knows what he does may even set up fcaps on executable files when the related
support-software is not installed, just because the unstable kernel interfaces 
are accessible from libc.

Do you like people to be able to open security holes?

Jörg

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

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

[Daniel Pielmeier]

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

2013/4/29 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>

> Nikos Chantziaras <realnc@gmail.com> wrote:
>
> > > This may be an option for things that really are optional.
> > >
> > > Libcap however is not something optional but needed to support a basic
> security
> > > feature.
> >
> > I thought it is optional, since it was mentioned that cdrtools can be
> > built and ran without it?
>
> If you call something that is needed in order to prevent security holes
> "optional", you may call it optional.
>
>
> > Unless you mean "recommended" instead of "required."  "Recommended"
> > means it's still optional.
>
> Is something to grant security optional or required?
>
>
> > > As mentioned above, we are talking about a library to support basic
> security
> > > features, so the code from that library would really belong into libc.
> Since
> > > Linux now by default supports fcaps in the filesystems, cdrecord would
> open
> > > a security hole if the library was not used - without that library,
> cdrecord
> > > cannot even see that is has been called with additional privileges
> that need
> > > to be removed before the main code is executed.
> > >
> > > Do you really like to go into a security risk with your eyes open?
> >
> > You don't know what my intentions are.  I might be doing testing,
> > debugging, who knows what.  It's the "trying to be smarter than the
> > user" thing.  The defaults of course would be to built the software in a
> > sane, secure way.  Only users who know what they're doing would disable
> > that, and they'd have their reasons.
>
> Would you call someone who shoots himself into the foot "smart"?
>
> Recent Linux kernels support fcaps in the filesystems and "somebody" evil,
> who
> knows what he does may even set up fcaps on executable files when the
> related
> support-software is not installed, just because the unstable kernel
> interfaces
> are accessible from libc.
>
> Do you like people to be able to open security holes?
>
>
>
>
>


Adding an option to enable/disable linkage to libcap does not hurt anybody
it just eases maintaining the package. You can enable it by default if you
wish.

As long as it is possible to remove libcap from the system the security
hole you are talking about is still there. The option does not change
anything. Currently one could still compile cdrtools without libcap and
afterwards install libcap and use setcap on cdrecord et al. which leads to
the same problem.

-- 
Regards
Daniel Pielmeier

[-- Attachment #2: Type: text/html, Size: 3401 bytes --]

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

[Joerg Schilling]

Daniel Pielmeier <billie@gentoo.org> wrote:

> 2013/4/29 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>

> > Do you like people to be able to open security holes?
>
> Adding an option to enable/disable linkage to libcap does not hurt anybody
> it just eases maintaining the package. You can enable it by default if you
> wish.
>
> As long as it is possible to remove libcap from the system the security
> hole you are talking about is still there. The option does not change
> anything. Currently one could still compile cdrtools without libcap and
> afterwards install libcap and use setcap on cdrecord et al. which leads to
> the same problem.

OK, I could create such an option.

I just don't like people to be able to do this without knowing that there is a 
potential security problem if the cdrecord binary has been assigned file caps
but cdrecord doesn't understand that it is running with enhanced privileges.

So I hope that from this discussion people here will remember the problem in 
case that somebody later runs into it.

Jörg

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

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

[Daniel Pielmeier]

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

Joerg Schilling schrieb am 29.04.2013 18:36:
> Daniel Pielmeier <billie@gentoo.org> wrote:
> 
>> 2013/4/29 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>
> 
>>> Do you like people to be able to open security holes?
>>
>> Adding an option to enable/disable linkage to libcap does not hurt anybody
>> it just eases maintaining the package. You can enable it by default if you
>> wish.
>>
>> As long as it is possible to remove libcap from the system the security
>> hole you are talking about is still there. The option does not change
>> anything. Currently one could still compile cdrtools without libcap and
>> afterwards install libcap and use setcap on cdrecord et al. which leads to
>> the same problem.
> 
> OK, I could create such an option.
> 
> I just don't like people to be able to do this without knowing that there is a 
> potential security problem if the cdrecord binary has been assigned file caps
> but cdrecord doesn't understand that it is running with enhanced privileges.
> 
> So I hope that from this discussion people here will remember the problem in 
> case that somebody later runs into it.
> 
> Jörg
> 

Thank you very much. I'd appreciate that. I think on Gentoo I can take
the measures that such things do not happen.

From the distro perspective everything should be okay. Cdrtools is
either installed suid root without capabilities and not linked against
libcap or it is installed with capabilities and linked against libcap.

If users are messing with setcap they should know what they are doing or
they are on their own.

Thank you for your support.

-- 
Regards
Daniel Pielmeier


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Nikos Chantziaras]

On 29/04/13 17:22, Joerg Schilling wrote:
> Nikos Chantziaras <realnc@gmail.com> wrote:
>> You don't know what my intentions are.  I might be doing testing,
>> debugging, who knows what.  It's the "trying to be smarter than the
>> user" thing.  The defaults of course would be to built the software in a
>> sane, secure way.  Only users who know what they're doing would disable
>> that, and they'd have their reasons.
>
> Would you call someone who shoots himself into the foot "smart"?
>
> Recent Linux kernels support fcaps in the filesystems and "somebody" evil, who
> knows what he does may even set up fcaps on executable files when the related
> support-software is not installed, just because the unstable kernel interfaces
> are accessible from libc.
>
> Do you like people to be able to open security holes?

You don't know what my intentions are and why I want to disable libcap. 
  I have my reasons.  This happens because it is actually possible to 
disable it.

If you really don't like that, then you should probably make libcap 
mandatory.  Assume it's there, and if it's not, the user should get 
compile errors.

But as long as it's not mandatory, I have my reasons why I would want to 
disable it, just as I have my reasons why I would want to explicitly 
enable it.  What if autodetection fails?  If I use the appropriate 
"enable libcap" flag, and libcap is not there, or it's broken, or 
whatever, I don't want to get a build that's now insecure.  I want the 
build to abort with a big, fat error.

I think you're too used to binary distros and Solaris to appreciate the 
different requirements of source-based distros :-)

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

[Joerg Schilling]

Nikos Chantziaras <realnc@gmail.com> wrote:

> > Would you call someone who shoots himself into the foot "smart"?
> >
> > Recent Linux kernels support fcaps in the filesystems and "somebody" evil, who
> > knows what he does may even set up fcaps on executable files when the related
> > support-software is not installed, just because the unstable kernel interfaces
> > are accessible from libc.
> >
> > Do you like people to be able to open security holes?
>
> You don't know what my intentions are and why I want to disable libcap. 
>   I have my reasons.  This happens because it is actually possible to 
> disable it.

I explained why not having libcap by default is a security risk.

You would need to explain your reasons, I currently cannot see a valid 
reason to exclude a very small piece of security relevant software.

> If you really don't like that, then you should probably make libcap 
> mandatory.  Assume it's there, and if it's not, the user should get 
> compile errors.

If you don't like my explanations, you are free to explain your reasons.

> But as long as it's not mandatory, I have my reasons why I would want to 
> disable it, just as I have my reasons why I would want to explicitly 
> enable it.  What if autodetection fails?  If I use the appropriate 
> "enable libcap" flag, and libcap is not there, or it's broken, or 
> whatever, I don't want to get a build that's now insecure.  I want the 
> build to abort with a big, fat error.
>
> I think you're too used to binary distros and Solaris to appreciate the 
> different requirements of source-based distros :-)

Solaris is source based too.....

The real difference to Linux is that Solaris uses a kernel that is 
auto-adjusting to the hardware and usage because it is fully dynamically loaded 
and because all parameters adjust themself to any needed value as long as there 
is enough kernel memory.

Linux has a large statically linked part and in theory you may be able to 
compile it  without capabilities, but then you would still need to have the 
userland support-code available to permit userland programs to find out whether 
the current kernel includes support or not.

...it is a matter of understaning security related constraints...

Jörg

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

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

[Nikos Chantziaras]

On 30/04/13 11:50, Joerg Schilling wrote:
> Nikos Chantziaras <realnc@gmail.com> wrote:
>
>>> Would you call someone who shoots himself into the foot "smart"?
>>>
>>> Recent Linux kernels support fcaps in the filesystems and "somebody" evil, who
>>> knows what he does may even set up fcaps on executable files when the related
>>> support-software is not installed, just because the unstable kernel interfaces
>>> are accessible from libc.
>>>
>>> Do you like people to be able to open security holes?
>>
>> You don't know what my intentions are and why I want to disable libcap.
>>    I have my reasons.  This happens because it is actually possible to
>> disable it.
>
> I explained why not having libcap by default is a security risk.
>
> You would need to explain your reasons, I currently cannot see a valid
> reason to exclude a very small piece of security relevant software.

I already did that:

> If I use the appropriate
> "enable libcap" flag, and libcap is not there, or it's broken, or
> whatever, I don't want to get a build that's now insecure.  I want the
> build to abort with a big, fat error.

Automagic deps are bad thing.  I want to know what's going on, and need 
to have a way to make sure that something is indeed enabled/disabled.


>> If you really don't like that, then you should probably make libcap
>> mandatory.  Assume it's there, and if it's not, the user should get
>> compile errors.
>
> If you don't like my explanations, you are free to explain your reasons.

I already did.  The "you don't know what I intend" part is there to 
cover use cases you cannot foresee.  Just because we can't think of them 
doesn't they don't exist.


>> But as long as it's not mandatory, I have my reasons why I would want to
>> disable it, just as I have my reasons why I would want to explicitly
>> enable it.  What if autodetection fails?  If I use the appropriate
>> "enable libcap" flag, and libcap is not there, or it's broken, or
>> whatever, I don't want to get a build that's now insecure.  I want the
>> build to abort with a big, fat error.
>>
>> I think you're too used to binary distros and Solaris to appreciate the
>> different requirements of source-based distros :-)
>
> Solaris is source based too.....

I don't see how.  Unless you mean that you can build from source on it. 
  Which isn't the same thing.


> The real difference to Linux is that Solaris uses a kernel that is
> auto-adjusting to the hardware and usage because it is fully dynamically loaded
> and because all parameters adjust themself to any needed value as long as there
> is enough kernel memory.

Gentoo isn't Solaris though.  Automagic deps cause problems on user's 
systems here.


> Linux has a large statically linked part and in theory you may be able to
> compile it  without capabilities, but then you would still need to have the
> userland support-code available to permit userland programs to find out whether
> the current kernel includes support or not.
>
> ...it is a matter of understaning security related constraints...

Understanding the problems of automagic deps on source-based Linux is 
also important.

Question though: if it's that important to have libcap, why do you 
provide a way to build the software without it?  Why not just make it 
mandatory?