[opensuse-project] Does openSUSE have an opinion of "Linux capabilities"?
All, I just read http://www.h-online.com/security/news/item/Expert-Linux-capabilities-don-t-a... And it left me wondering if openSUSE has a plan related to capabilities. Apparently some of the distros are moving to it rapidly in an effort to eliminate SUID programs, but there may be security holes in the new concept too, so it's pretty up in the air. And my other question is where do project level design concepts like this get discussed? Thanks Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2011/1/12 Greg Freemyer <greg.freemyer@gmail.com>:
And it left me wondering if openSUSE has a plan related to capabilities. Apparently some of the distros are moving to it rapidly in an effort to eliminate SUID programs, but there may be security holes in the new concept too, so it's pretty up in the air.
And my other question is where do project level design concepts like this get discussed?
https://features.opensuse.org/307254 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Jan 12, 2011 at 3:51 PM, Cristian Morales Vega <cmorve69@yahoo.es> wrote:
2011/1/12 Greg Freemyer <greg.freemyer@gmail.com>:
And it left me wondering if openSUSE has a plan related to capabilities. Apparently some of the distros are moving to it rapidly in an effort to eliminate SUID programs, but there may be security holes in the new concept too, so it's pretty up in the air.
And my other question is where do project level design concepts like this get discussed?
That looks more like a technical discussion which seems very appropriate. But in this case I was hoping for a statement of direction. ie. "The openSUSE community has decided to restrict the use of SUID by switching to Linux Capabilities instead and is targeting the 12.0 release to have no SUID programs included in the release." would be a statement of direction. It seems high-level direction like this is only provided via rpmlint telling packagers that their packages are no longer accepted. Non-packagers have no idea. It seems there should at least be a wiki page that tracks these types of rpmlint enforced initiatives. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Greg Freemyer wrote:
On Wed, Jan 12, 2011 at 3:51 PM, Cristian Morales Vega <cmorve69@yahoo.es> wrote:
2011/1/12 Greg Freemyer <greg.freemyer@gmail.com>:
And it left me wondering if openSUSE has a plan related to capabilities. Apparently some of the distros are moving to it rapidly in an effort to eliminate SUID programs, but there may be security holes in the new concept too, so it's pretty up in the air.
And my other question is where do project level design concepts like this get discussed?
That looks more like a technical discussion which seems very appropriate.
But in this case I was hoping for a statement of direction.
ie. "The openSUSE community has decided to restrict the use of SUID by switching to Linux Capabilities instead and is targeting the 12.0 release to have no SUID programs included in the release." would be a statement of direction.
That would require leadership, foresight and planning. -- Per Jessen, Zürich (7.9°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 13 January 2011 08:05:35 Per Jessen wrote:
Greg Freemyer wrote:
On Wed, Jan 12, 2011 at 3:51 PM, Cristian Morales Vega
<cmorve69@yahoo.es> wrote:
2011/1/12 Greg Freemyer <greg.freemyer@gmail.com>:
And it left me wondering if openSUSE has a plan related to capabilities. Apparently some of the distros are moving to it rapidly in an effort to eliminate SUID programs, but there may be security holes in the new concept too, so it's pretty up in the air.
And my other question is where do project level design concepts like this get discussed?
That looks more like a technical discussion which seems very appropriate.
But in this case I was hoping for a statement of direction.
ie. "The openSUSE community has decided to restrict the use of SUID by switching to Linux Capabilities instead and is targeting the 12.0 release to have no SUID programs included in the release." would be a statement of direction.
That would require leadership, foresight and planning.
Or just someone who feels like taking this on. THEN such a statement could be produced.
Greg Freemyer wrote:
On Wed, Jan 12, 2011 at 3:51 PM, Cristian Morales Vega <cmorve69@yahoo.es> wrote:
2011/1/12 Greg Freemyer <greg.freemyer@gmail.com>:
And it left me wondering if openSUSE has a plan related to capabilities. Apparently some of the distros are moving to it rapidly in an effort to eliminate SUID programs, but there may be security holes in the new concept too, so it's pretty up in the air.
And my other question is where do project level design concepts like this get discussed?
That looks more like a technical discussion which seems very appropriate.
But in this case I was hoping for a statement of direction.
ie. "The openSUSE community has decided to restrict the use of SUID by switching to Linux Capabilities instead and is targeting the 12.0 release to have no SUID programs included in the release." would be a statement of direction.
Noone has decided anything AFAIK. Unless someone goes ahead and actually adjusts the packages¹ nothing is going to change anyways. I've just implemented the ground work that allows packagers to have fscaps enabled binaries. However, blindly putting e.g. CAP_SYS_ADMIN on a binary instead of having it setuid would be just windows dressing and in some cases even worse than setuid. So the statement above doesn't really tell anything about security gains. A better goal would be to eliminate the need for setuid/fscaps binaries in the first place. The Fedora fscaps initiative is piggybacking another feature though. They have changed root writeable files and directories to read only or even no access at all (e.g. 555 for /bin or 000 for /etc/shadow). That's really the interesting part as it locks out a root user that lacks CAP_DAC_OVERRIDE.
It seems high-level direction like this is only provided via rpmlint telling packagers that their packages are no longer accepted. Non-packagers have no idea.
It seems there should at least be a wiki page that tracks these types of rpmlint enforced initiatives.
rpmlint actually makes sure that packages contain *no* fscaps. fscaps are handled via /etc/permissions at runtime if the kernel supports it (the kernel-ml ignored my requests to include a patch to detect that properly though). cu Ludwig [1] $ grep -cv '^$\|^#' /etc/permissions.easy 213 good luck :-) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (5)
-
Cristian Morales Vega -
Greg Freemyer -
Jos Poortvliet -
Ludwig Nussel -
Per Jessen