Re: [gentoo-user] Re: Cdrtools installation without suid root
Nikos Chantziaras rea...@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: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] Re: Cdrtools installation without suid root
Joerg Schilling schrieb am 29.04.2013 18:36: Daniel Pielmeier bil...@gentoo.org wrote: 2013/4/29 Joerg Schilling joerg.schill...@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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Cdrtools installation without suid root
Daniel Pielmeier bil...@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: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] Re: Cdrtools installation without suid root
Nikos Chantziaras rea...@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: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] Re: Cdrtools installation without suid root
Nikos Chantziaras rea...@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: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] Re: Cdrtools installation without suid root
2013/4/29 Joerg Schilling joerg.schill...@fokus.fraunhofer.de Nikos Chantziaras rea...@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
Re: [gentoo-user] Re: Cdrtools installation without suid root
Daniel Pielmeier bil...@gentoo.org wrote: 2013/4/29 Joerg Schilling joerg.schill...@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: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] Re: Cdrtools installation without suid root
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 signature.asc Description: OpenPGP digital signature
