[opensuse-factory] debugfs mounted by default - necessary?
Hi, is it necessary that "debugfs" is mounted by default? It exposes too much of the kernel readable (and so potentially exploitable) to the non-root user. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 05, 2011 at 05:11:58PM +0100, Marcus Meissner wrote:
Hi,
is it necessary that "debugfs" is mounted by default?
perf needs/wants it, as does other things that we need for suportability (usb device list, etc.)
It exposes too much of the kernel readable (and so potentially exploitable) to the non-root user.
What is exploitable in debugfs, and "too readable"? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 05, 2011 at 08:22:01AM -0800, Greg KH wrote:
On Mon, Dec 05, 2011 at 05:11:58PM +0100, Marcus Meissner wrote:
Hi,
is it necessary that "debugfs" is mounted by default?
perf needs/wants it, as does other things that we need for suportability (usb device list, etc.)
It exposes too much of the kernel readable (and so potentially exploitable) to the non-root user.
What is exploitable in debugfs, and "too readable"?
I do not know if anything is exploitable. This is also more a look into the future. Too readable as in "exposing too much information normal users do not need". Seeing that even interrupt numbers / timings are used to guess passwords nearly any information can be a side channel of sensitive information. So: Does "perf" need to run as user, or can it just be run as "root"? Could we restrict the mount permissions of debugfs to only be root readable? Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 05, 2011 at 05:26:02PM +0100, Marcus Meissner wrote:
On Mon, Dec 05, 2011 at 08:22:01AM -0800, Greg KH wrote:
On Mon, Dec 05, 2011 at 05:11:58PM +0100, Marcus Meissner wrote:
Hi,
is it necessary that "debugfs" is mounted by default?
perf needs/wants it, as does other things that we need for suportability (usb device list, etc.)
It exposes too much of the kernel readable (and so potentially exploitable) to the non-root user.
What is exploitable in debugfs, and "too readable"?
I do not know if anything is exploitable. This is also more a look into the future.
Too readable as in "exposing too much information normal users do not need".
Again, what is exploitable today, it will be fixed.
Seeing that even interrupt numbers / timings are used to guess passwords nearly any information can be a side channel of sensitive information.
I understand your feeling that we are exposing "too much", but without a specific example of what is wrong here, I'm not going to want to see anything changed.
So: Does "perf" need to run as user, or can it just be run as "root"?
It can run as user, and it provides very good statistics as a user, you should try it sometime :)
Could we restrict the mount permissions of debugfs to only be root readable?
No, a patch to do so was rejected upstream for the reasons I cite above. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, I think it is a very deep conceptual issue and a very deep difference in thinking about availability of features... "As close and restricted as possible" vs "allow as much as possible". Lets see two cases: If you are building a nuclear power plant, you want everything specified and doing exactly the thing you want it to do, but nothing more. You want everything documented, proven to be only there if needed, and doing just the things it needs to do. If you are building an experimental herb and flower garden, you want random influences and as much potential as possible. A secure Linux server sadly should act more like a nuclear power plant as break ins will cause fallout than a herb garden. Ciao, Marcus On Mon, Dec 05, 2011 at 08:40:41AM -0800, Greg KH wrote:
Again, what is exploitable today, it will be fixed.
Seeing that even interrupt numbers / timings are used to guess passwords nearly any information can be a side channel of sensitive information.
I understand your feeling that we are exposing "too much", but without a specific example of what is wrong here, I'm not going to want to see anything changed.
So: Does "perf" need to run as user, or can it just be run as "root"?
It can run as user, and it provides very good statistics as a user, you should try it sometime :)
Could we restrict the mount permissions of debugfs to only be root readable?
No, a patch to do so was rejected upstream for the reasons I cite above.
thanks,
greg k-h
-- Working, but not speaking, for the following german company: SUSE LINUX Products GmbH, HRB 16746 (AG Nuernberg) Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 06, 2011 at 03:09:12PM +0100, Marcus Meissner wrote:
Hi,
I think it is a very deep conceptual issue and a very deep difference in thinking about availability of features...
"As close and restricted as possible" vs "allow as much as possible".
Lets see two cases:
If you are building a nuclear power plant, you want everything specified and doing exactly the thing you want it to do, but nothing more. You want everything documented, proven to be only there if needed, and doing just the things it needs to do.
If you are building an experimental herb and flower garden, you want random influences and as much potential as possible.
A secure Linux server sadly should act more like a nuclear power plant as break ins will cause fallout than a herb garden.
Again, what specifically is wrong with debugfs that is causing problems? Is it just the fear of the unknown? procfs "leaks" more system information today than debugfs does, do you want to not allow that to be mounted as well? This "fear of the unknown" for a feature of the kernel that has been there for a very long time is quite strange to me. And again, if there are problems found with any type of security related information leakage that should not be there in debugfs, let us know, it will get fixed. But don't outright ban the thing just because you are "afraid" of it, that's wrong. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 06, 2011 at 07:37:10AM -0800, Greg KH wrote: ...
Again, what specifically is wrong with debugfs that is causing problems?
Nothing.
Is it just the fear of the unknown?
The fear of the yet undiscovered problems.
procfs "leaks" more system information today than debugfs does, do you want to not allow that to be mounted as well?
You might be aware that I am one of the guys supporting that it exports _less_ information and that it already exports these days less than previous versions. /proc is so deep entrenched in compatibility concerns it is hard to do sadly.
This "fear of the unknown" for a feature of the kernel that has been there for a very long time is quite strange to me.
And again, if there are problems found with any type of security related information leakage that should not be there in debugfs, let us know, it will get fixed.
But don't outright ban the thing just because you are "afraid" of it, that's wrong.
Please try to think as a security worker for a short moment... "If there are problems, tell us, we fix it" ... this is the way the security world works today (and it works basically). But this is a huge and ever turning treadmill where we (security and developers) can barely keep up running. What we (security and likely our users) want is a smaller or lower running treadmill. This means reducing what we call (and should be self explanatory) "attack surface". And yes, it is fear. Fear of the "yet unknown security holes the blackhats know about" or for our users the fear of "unknown if hackers have broken in already because we have not all updates or unknown issues." Do you not manage server(s) and fear such breakins? Ciao, Marcus PS: You can now stop thinking like me again... :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 06, 2011 at 05:32:55PM +0100, Marcus Meissner wrote:
On Tue, Dec 06, 2011 at 07:37:10AM -0800, Greg KH wrote: ...
Again, what specifically is wrong with debugfs that is causing problems?
Nothing.
Is it just the fear of the unknown?
The fear of the yet undiscovered problems.
That fear will always be there, it conflicts with the need/want for new features and functionality.
This "fear of the unknown" for a feature of the kernel that has been there for a very long time is quite strange to me.
And again, if there are problems found with any type of security related information leakage that should not be there in debugfs, let us know, it will get fixed.
But don't outright ban the thing just because you are "afraid" of it, that's wrong.
Please try to think as a security worker for a short moment...
Please remember that my first full-time Linux job was as a security worker, I know this field very well. Because of that job, the whole LSM layer in the kernel was created to try to mitigate these types of problems, along with the product that today is called apparmor. That tool does mitigate the attack surface very well, and we support it for people who are worried about just such things.
"If there are problems, tell us, we fix it" ... this is the way the security world works today (and it works basically).
But this is a huge and ever turning treadmill where we (security and developers) can barely keep up running.
What we (security and likely our users) want is a smaller or lower running treadmill.
Of course, but then again, you need to balance it with the need of those same users for those new features and requirements. To shut down whole subsystems of the kernel just because you "fear" it, and have not audited it all to your satisfaction is one reaction, but one that again, goes against what has made Linux successful in the first place (fast moving where competitors did not.)
This means reducing what we call (and should be self explanatory) "attack surface".
And yes, it is fear.
Fear of the "yet unknown security holes the blackhats know about" or for our users the fear of "unknown if hackers have broken in already because we have not all updates or unknown issues."
Do you not manage server(s) and fear such breakins?
I do manage such servers, and I do reduce the attack surface on them. But here you are saying that you want to wholesale remove functionality by default, of systems that have already shipped, just because you now fear the unknown of what is in them. Why not take the 2-3 days and audit the files to remove that fear that you seem to have. That seems like the more sane aproach here, not going around saying "your 12.1 system is now exposed to the elements, quick, change the defaults because we really have no idea what is going on here!", which is what is happening now, right? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/6/2011 12:08 PM, Greg KH wrote:
On Tue, Dec 06, 2011 at 05:32:55PM +0100, Marcus Meissner wrote:
On Tue, Dec 06, 2011 at 07:37:10AM -0800, Greg KH wrote: ...
Again, what specifically is wrong with debugfs that is causing problems?
Nothing.
Is it just the fear of the unknown?
The fear of the yet undiscovered problems.
That fear will always be there, it conflicts with the need/want for new features and functionality.
This "fear of the unknown" for a feature of the kernel that has been there for a very long time is quite strange to me.
And again, if there are problems found with any type of security related information leakage that should not be there in debugfs, let us know, it will get fixed.
But don't outright ban the thing just because you are "afraid" of it, that's wrong.
Please try to think as a security worker for a short moment...
Please remember that my first full-time Linux job was as a security worker, I know this field very well. Because of that job, the whole LSM layer in the kernel was created to try to mitigate these types of problems, along with the product that today is called apparmor. That tool does mitigate the attack surface very well, and we support it for people who are worried about just such things.
"If there are problems, tell us, we fix it" ... this is the way the security world works today (and it works basically).
But this is a huge and ever turning treadmill where we (security and developers) can barely keep up running.
What we (security and likely our users) want is a smaller or lower running treadmill.
Of course, but then again, you need to balance it with the need of those same users for those new features and requirements.
To shut down whole subsystems of the kernel just because you "fear" it, and have not audited it all to your satisfaction is one reaction, but one that again, goes against what has made Linux successful in the first place (fast moving where competitors did not.)
This means reducing what we call (and should be self explanatory) "attack surface".
And yes, it is fear.
Fear of the "yet unknown security holes the blackhats know about" or for our users the fear of "unknown if hackers have broken in already because we have not all updates or unknown issues."
Do you not manage server(s) and fear such breakins?
I do manage such servers, and I do reduce the attack surface on them. But here you are saying that you want to wholesale remove functionality by default, of systems that have already shipped, just because you now fear the unknown of what is in them.
Why not take the 2-3 days and audit the files to remove that fear that you seem to have. That seems like the more sane aproach here, not going around saying "your 12.1 system is now exposed to the elements, quick, change the defaults because we really have no idea what is going on here!", which is what is happening now, right?
thanks,
greg k-h
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place. Rather than say "look it all over and try to find something that is exploitable" instead the more robust method says "find the 3 things some app actually needs, and then only expose thise, and even try to see if there's a way to only expose those few needed things to those few apps that need them." Do you install all possible software on important servers and simply assume that it's all safe and isn't providing the tools for some attack or even some mere accident, or do you install just the software that a given server actually needs to do it's job? Do you enable services you don't actually need on important servers and just assume that since you didn't give anyone logins to them, that no harm is being done by having them sitting there all day every day? Or do you only enable those services that are actually needed for that particular box to do it's job? What is wrong with his argument? Does it not fall under the same category as these examples? I don't think focusing on the word "fear" and all it's implications is a fair treatment of the question. Asking "what's broken?" does not answer the question of "Is this seemingly large area of risk necessary?". You did point out that there is already even more data exposed elsewhere, which doesn't exactly answer the question of why this data is so necessary nor prove that it's so garanteed harmless. As he has now responded, he does in fact consider /proc to be overdue for review also for the same reasons. Just because /proc has been there a long time does not make it less of a potential problem. It just makes it harder to deal with. Maybe proc and debug are actually in some way fundamentally safe without having to worry about them. But I see nothing intrinsically wrong with the question. Suppose today, you go through everything in debugfs and somehow prove there is nothing abuse-able anywhere in there. Suppose tomorrow you perform a kernel update and end up with a new or modified driver that places something new in debugfs that wasn't there yesterday and is a complete gift to hackers. Having no debugfs because you determined that you didn't actually need it would have saved you from getting bitten by the problem without you having to have predicted the problem. This seems like pretty basic math. The concept applies in all of engineering in every field not just security. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/11 16:10, Brian K. White wrote:
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place.
isn't that essentially "security through obscurity" (aka, path to fail ? ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 06, 2011 at 07:20:54PM -0300, Cristian Rodríguez wrote:
On 06/12/11 16:10, Brian K. White wrote:
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place.
isn't that essentially "security through obscurity" (aka, path to fail ? )
What Brian suggested isn't security by obscurity. It's a simple and passive approach. To me he illustrated it well with running but not needed services. Each non listening port can't cause a risk, never can be exploited. It's quite obvious that enabled/ running services are subject of the well known secure coding rules. This includes reviews as they are performed for example by the SUSE security team. From the rules how the security team values incidents - is a service started by default, does it listen on external interfaces, is it run as non root user, inside of a chroot - Marcus' arguments sound quite well. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 12/6/2011 5:20 PM, Cristian Rodríguez wrote:
On 06/12/11 16:10, Brian K. White wrote:
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place.
isn't that essentially "security through obscurity" (aka, path to fail ? )
Security through obscurity is an unrelated concept. Security through obscurity would be placing something in 666 file somewhere but just not telling anyone it's there and hoping no one thinks to look there. That has nothing to do with this. Not including or using features you don't actually need is a key part of an overall pattern of maximizing security. If you want a catch phrase, including unnecessary features and hoping they are all safe, or relying on some other layer of security elsewhere to prevent access to them is "eggshell security". -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/11 16:10, Brian K. White wrote:
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place.
So, what you are really saying is that you don't trust the kernel developers to get things right? Seriously, I've yet to see one specific example of a debugfs file that is "unsafe" in todays kernel. I understand the wish for some people to "control the exposed area", but if I take that to its logical conclusion, the same people will want the option to disable system calls that they feel no one should ever use as well? I still see this whole thing as basic "fear of the unknown". To solve that, make it "known". Seriously, audit the code, it's there for all to see. If you see problems with it, it will be fixed. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.12.2011 01:03, schrieb Greg KH:
On 06/12/11 16:10, Brian K. White wrote:
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place.
So, what you are really saying is that you don't trust the kernel developers to get things right?
Of course I don't :-) Seriously: There are errors. Even in the Kernel. I found lots of them. Are all available packages installed on your servers with all services turned on listening on external interfaces? Why not? Oh! You don't trust the developers of those packages to get things right? ;-)
Seriously, I've yet to see one specific example of a debugfs file that is "unsafe" in todays kernel.
Seriously, I've yet to see proof that no debugfs file will be unsafe in tomorrows kernel.
but if I take that to its logical conclusion, the same people will want the option to disable system calls that they feel no one should ever use as well?
If it is obscure, seldom used stuff: why not? I do, for example, never load the AX25 and ROSE drivers (even though I have a license to use the equipment they talk to). Why not? Because I don't need them. So there were quite some Kernel updates in the past I could safely skip because they fixed security bugs in those protocols.
I still see this whole thing as basic "fear of the unknown". To solve that, make it "known". Seriously, audit the code, it's there for all to see. If you see problems with it, it will be fixed.
Even though perf might be a great tool for developers, my wife and kids have never used it. And I have machines without debugfs that work very well, so it is obviously not essential in order tu run a useful linux system. I guess that debugfs even occupies some memory that could be spent for yet another firefox tab ;-) Best regards, Stefan -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 07, 2011 at 07:33:37AM +0100, Stefan Seyfried wrote: ...
If it is obscure, seldom used stuff: why not? I do, for example, never load the AX25 and ROSE drivers (even though I have a license to use the equipment they talk to). Why not? Because I don't need them. So there were quite some Kernel updates in the past I could safely skip because they fixed security bugs in those protocols.
Actually you shouldn't have skipped them, because these protocols are autoloadable by regular users and the exploits. (you just need to create a socket with AF_ROSE or AF_AX25 to load them). So the root exploits in those modules worked because the kernel was (and I think still is) autoloading network modules on demand. All in all it is less "fear of the unknown" but a call for application of "Principle of least privilege" ( http://en.wikipedia.org/wiki/Principle_of_least_privilege ) For what it is worth, the 504 resolved kernel bugs in my buglist were handled competently by kernel developers and I guess the future ones will too. It just would have been way better if those bugs would never had been there. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.12.2011 14:10, schrieb Marcus Meissner:
Actually you shouldn't have skipped them, because these protocols are autoloadable by regular users and the exploits. (you just need to create a socket with AF_ROSE or AF_AX25 to load them).
So the root exploits in those modules worked because the kernel was (and I think still is) autoloading network modules on demand.
"find /lib/modules/ -name rose.ko -o -name ax25.ko|xargs rm" did help to prevent that. Enough OT ;-)
All in all it is less "fear of the unknown" but a call for application of "Principle of least privilege" ( http://en.wikipedia.org/wiki/Principle_of_least_privilege )
I agree. I really want a useful distribution. Useful in a sense that I can do my work easily with as little distraction due to security stuff as possible. However, judging that I never have used perf nor ever looked into debugfs, I wonder why I want to have it mounted by default. Best regards, Stefan -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Dec 06, 2011 at 04:03:17PM -0800, Greg KH wrote:
On 06/12/11 16:10, Brian K. White wrote:
Having a lot lot of stuff exposed and believing that it's all ok is fundamentally less secure than not exposing anything in the first place.
So, what you are really saying is that you don't trust the kernel developers to get things right?
Seriously, I've yet to see one specific example of a debugfs file that is "unsafe" in todays kernel. I understand the wish for some people to "control the exposed area", but if I take that to its logical conclusion, the same people will want the option to disable system calls that they feel no one should ever use as well?
Of course you fixed all known issues. (here are some: http://openwall.com/lists/oss-security/2011/02/22/4 http://www.openwall.com/lists/oss-security/2011/01/24/5 ) The kernel developers so far fixed the ones that appeared in good time and quality (well, except for by CVE documentation, but thats another topic). The problem with security problems is however also the time window between those 4 steps in the timeline: "Blackhats know it and exploit it" "The kernel community knows it and has fixed it" "The distributors have shipped the fix" "The admins have deployed the fix" which usually are counted in weeks if not months or years. So avoiding security bugs altogether is even better then getting them fixed fast for all including the system admins. Reducing the attack surface is one method, even if there are no known issues. That I have 504 fixed kernel security bugs in my bugtracker is perhaps one point explaining my insistence on reducing the attack surface. That 33 are open and yet to be fixed in my bugtracker is also not helping.
I still see this whole thing as basic "fear of the unknown". To solve that, make it "known". Seriously, audit the code, it's there for all to see. If you see problems with it, it will be fixed.
"principle of least privilege" is probably the better wording. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/12/11 10:49, Marcus Meissner wrote:
"principle of least privilege" is probably the better wording.
Which usually becomes the "principle of least possible usability" :-( -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian RodrC-guez wrote:
On 07/12/11 10:49, Marcus Meissner wrote:
"principle of least privilege" is probably the better wording.
Which usually becomes the "principle of least possible usability" :-(
---- Bingo. Principle of least privilege is great for systems designed to constrain and control users. You want to keep users under your thumb and allow them nothing unless they need it. That how the US government is becoming... The alternative is 'freedom' -- and educating users how to responsibly use that freedom. But in doing that -- you create users with more 'self power' -- not good if you are trying to center/gather power at the top. The US was built in an attempt to create a shared and distributed, on the idea that it would grow best by giving local authorities carte-blank except in key areas needed to be controlled by the central authority. Unix was created in the same spirit -- to enable people .. not to control them (look to VMS/ IBM for those OS's). Those controlling OS's are all but dead, and the innovation coming from those under those systems is likely VERY different from the level of innovation of someone developing on an open platform. In short. A desired for a 'controlled/controlling' system to be the 'default' is a reflection of wanting to dominate and control users -- which will lead to lower productivity (which as happened in the US as more freedoms were taken by the government (and made illegal), the US's economy has suffered -- instead of finding fulfillment through work and acquiring new knowledge, people are encouraged to have fun in beer football, and playing politics to see who can become the most powerful (at the expense of the rest of the players). Linux/Unix is designed top be open as it was designed to be LEARNED from. We don't want to hide thigns by *default* ... (which says nothing about making it have the ability to be configured 'closed' -- flexibility and configurability are good things). But the default configuration going out to users -- should be 'open' and transparent. And importantly -- an open source allows end users to discover flaws and more quickly fix them and/or work around them, vs. closed source OS's like *R*X, that had 10's of thousands of bugs filed against it (many from internal people). But policy was to only fix those bugs when a paying customer found them. The most secure system is one that is open and transparent -- where everyone can see the security code -- but even knowing the formulae, doesn't give them access, or benefit, as the algorithms create authentication tokens on the fly that are not decipherable/decryptable in any useful time period. I.e. it's security through good design, vs. security though obscurity -- and yes, a closed up system is a form of security through obscurity.... you may not be hiding passwords in the code, but you are hiding algorithms in the code, that, in well designed ones, don't give you any advantage. Their advantage is in the algorithm, not whether or not the algorithm is known. Please think about that Marcus. I'm 100% with you in having the *options* for strong hardening present, but don't think they should be the default... it's not the write-mindset for the space, IMO.... -linda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 07, 2011 at 10:44:55AM -0800, Linda Walsh wrote:
Cristian RodrC-guez wrote:
On 07/12/11 10:49, Marcus Meissner wrote:
"principle of least privilege" is probably the better wording.
Which usually becomes the "principle of least possible usability" :-(
---- Bingo.
Principle of least privilege is great for systems designed to constrain and control users. You want to keep users under your thumb and allow them nothing unless they need it. That how the US government is becoming... ... long e-mail deleted ... Please think about that Marcus. I'm 100% with you in having the *options* for strong hardening present, but don't think they should be the default... it's not the write-mindset for the space, IMO....
After your very long e-mail I have one question... Do you think that security has a too tight grasp on the current openSUSE releases up to now? If you are happy with the current state ... ... then my teams work is sufficiently balanced security vs features, as we are watching over openSUSE since the beginning. My intention originally was not to go and veto useful features. The intention was to bring up awareness that there is risk and how to keep them lower. That said I currently see nothing in debugfs that warrants a veto from security side, except perhaps having a way to mount it root-only or disable it easily for people hardening systems. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/7/2011 1:44 PM, Linda Walsh wrote:
Cristian RodrC-guez wrote:
On 07/12/11 10:49, Marcus Meissner wrote:
"principle of least privilege" is probably the better wording.
Which usually becomes the "principle of least possible usability" :-(
---- Bingo.
Principle of least privilege is great for systems designed to constrain and control users. You want to keep users under your thumb and allow them nothing unless they need it. That how the US government is becoming...
The alternative is 'freedom' -- and educating users how to responsibly use that freedom. But in doing that -- you create users with more 'self power' -- not good if you are trying to center/gather power at the top.
The US was built in an attempt to create a shared and distributed, on the idea that it would grow best by giving local authorities carte-blank except in key areas needed to be controlled by the central authority.
Unix was created in the same spirit -- to enable people .. not to control them (look to VMS/ IBM for those OS's). Those controlling OS's are all but dead, and the innovation coming from those under those systems is likely VERY different from the level of innovation of someone developing on an open platform.
In short. A desired for a 'controlled/controlling' system to be the 'default' is a reflection of wanting to dominate and control users -- which will lead to lower productivity (which as happened in the US as more freedoms were taken by the government (and made illegal), the US's economy has suffered -- instead of finding fulfillment through work and acquiring new knowledge, people are encouraged to have fun in beer football, and playing politics to see who can become the most powerful (at the expense of the rest of the players).
Linux/Unix is designed top be open as it was designed to be LEARNED from. We don't want to hide thigns by *default* ... (which says nothing about making it have the ability to be configured 'closed' -- flexibility and configurability are good things). But the default configuration going out to users -- should be 'open' and transparent. And importantly -- an open source allows end users to discover flaws and more quickly fix them and/or work around them, vs. closed source OS's like *R*X, that had 10's of thousands of bugs filed against it (many from internal people). But policy was to only fix those bugs when a paying customer found them.
The most secure system is one that is open and transparent -- where everyone can see the security code -- but even knowing the formulae, doesn't give them access, or benefit, as the algorithms create authentication tokens on the fly that are not decipherable/decryptable in any useful time period.
I.e. it's security through good design, vs. security though obscurity -- and yes, a closed up system is a form of security through obscurity.... you may not be hiding passwords in the code, but you are hiding algorithms in the code, that, in well designed ones, don't give you any advantage. Their advantage is in the algorithm, not whether or not the algorithm is known.
Please think about that Marcus. I'm 100% with you in having the *options* for strong hardening present, but don't think they should be the default... it's not the write-mindset for the space, IMO....
-linda
This isn't about freedom. This is simple robust design vs cross-your-fingers-and-pray design. Yet another analogy that uses already accepted wisdom to make the point that should never have been up for debate in the first place: This is approximately the same thing as why "you just do not log in as root for day to day use". You log in as root only when you need to for some specific reason, the rest of the time you operate as a user with vastly reduced privileges. The reasons why are well explained many times over to every new unix admin, and Windows too for that matter, and the theory is beyond any doubt or debate. This has nothing to do with freedom. Please do not try to warp the conversation with emotional misdirection. The ludicrous extreme examples like "turn the machine off and it's even safer" are likewise invalid attempts at misdirection. The electricity is actually a necessary function for most users by default. That fact that the machine is running and does anything at all is a necessary function for most users by default. No one has yet shown that debugfs is a necessary function for most users by default. Can you not view a web page, play an mp3, edit a document, send an email, without debugfs? I'm not actually saying debugfs is necessarily so horrible, but so far the arguments presented here against the OP's questioning of it being enabled by default for everyone, have been stupid and invalid and have missed the core point of robust design in general, let alone in the security context. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7 December 2011 14:11, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
On 07/12/11 10:49, Marcus Meissner wrote:
"principle of least privilege" is probably the better wording.
Which usually becomes the "principle of least possible usability" :-(
That's why Marcus asked before. From Greg's description ("perf needs/wants it, as does other things that we need for suportability (usb device list, etc.)") it looks like we can have an exhaustive list of what needs it and it will not be very long? If that list could be provided we could better decide what's the best usability/security compromise. No idea about what "usb device list" really implies. But if it where only because of perf IMHO it would not make sense to mount debugfs *by default*. If someone is interested in cache-misses surely he can mount debugfs by himself (supposing there is no way to automatize this). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Brian K. White -
Cristian Morales Vega -
Cristian Rodríguez -
Greg KH -
Lars Müller -
Linda Walsh -
Marcus Meissner -
Stefan Seyfried