(more) secure filesystem permissions

I've noticed that default filesystem permissions for a lot of distros seem a little lax. I'm wondering what changes might be of use, especially for preventing information gathering and privilege escalation on multiuser setups.

e.g.

/boot - Default permissions are drwxr-xr-x. Why is anyone other than root allowed to read stuff in there? The kernel config file could reveal potential vulnerabilities, no?

/lib/modules, /lib/firmware - Likewise, if using a custom kernel or third-party firmware.

/var/log - Likewise, unless someone needs to read logs from a limited account (which should probably be handled with groups I guess).

I'm also kind kind of curious about ways of hardening virtual filesystems like /proc and /sys. It would be nice if limited users could be denied read access to process entries owned by root, or by other limited users... Or something along those lines. Assuming such things are possible without crippling the system anyway.

BTW I do realize this stuff is not so useful on a desktop, where you're owned as soon as someone gains control of Firefox... Just interested in the limits of discretionary access control.

Edit: also - does anyone know some way to prevent package managers from clobbering directory permissions? Because I could see that getting real annoying real fast.

 

http://www.gentoo.org/proj/en/hardened/

Have you tried this, you can get it in Sabayon.

 

Thanks, though that is something completely different... Probably more appropriate for a multiuser environment though.

 

As soon as someone gains control of ... who/when/how. Are we gonna do sci-fi again?
The permissions are as they are because that's how they are meant to be.
Reading the kernel config does not reveal potential vulnerabilities, at all.
The operating system is MORE than just paranoid security.
People actually USE their systems for something.

Mrk

 

If I were an attacker there are tons of better ways to gain details on your vulnerabilities. That's what nessus is for, and all that requires is knowing your IP. Plus if he's reading these files then he's already on your system and you're already owned. Here's my take on this: you're trying to manage an attacker once he's already on your system. I think the time would be better spent to prevent him from getting on the system in the first place. There are tons of security tools/toys/options to make it really incredibly annoying for an attacker. Once an attacker gets on your system and you discover it, you're going to reinstall anyway, right? Would you trust that he didn't fully escalate his privileges or hide some nasty package?

I don't see the problem with allowing non-root to read the logs if they can't change them. The Ubuntu Guest account doesn't have access to read the logs, but the sudo user does. I'm sure other distros handle it similarly.

 

Not sure why they're allowed to read /boot, but I assume there's a legitimate reason. Have you tried restricting it?

Yes, you'd still want to reformat. But creating strong local security is still important. An attackers goals may require root, they may require some new permissions, etc. When a program is compromised we can assume all programs and information of that UID are compromised, but I don't think we need to assume they got root unless there's a reason to. We can take the extra cautious steps to reformat etc. but idk, there's still reason to protect against local attacks imo.

 

For desktop environments I'd agree to a point. People use their systems for many different purposes/functions and its very easy to limit directories/ remove unnecessary accounts/services/packages, and lock down a system more than how it is bundled and still use the system effectively with no issues. Leaving a system/services as is from install is foolish if its going to be doing something other than a home user's personal feet warmer and public facing.

Good auditing rules and utilizing integrity tools such as AIDE (freeware version of Tripwire) can really help determine what was compromised if anything.

[edit] For Gullible Jones, while these are more so for RHEL/CentOS servers the following guide can assist you as a starting point of where to harden your desktop/server and applications:

1. (- http://iase.disa.mil/stigs/os/unix/red_hat.html - )
2. ( - http://iase.disa.mil/stigs/app_security/browser_guidance/browser_guidance.html - )