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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org