Add more hardening options to the default profile in etc #151
Conversation
|
The group does not need to be restricted. If username is In the past, we've changed the default umask (though through a different implementation), had run into unreasonable issues and then settled for a different solution (permission-lockdown). That's quite some time ago and I'd have to re-read this: Changes in where some extra output by The suggested umask change: The suggested |
|
All your contributions are most helpful and appreciated! |
Debian uses 0022 per default. It means when we create a directory for example, the permission is set to 755. This means, the group and others can read and execute, but they can't write. With 0077 we would deny them even reading. All the security guides I read recommend a minimum of 0027 umask. Debian's official guide is one of them. I know this does not break anything on a personal computer, or on a vm. But I don't know anything about qubes. They do their stuff differently and there are more things to consider there. |
|
Having read the old forum threads, I gather that most problems that are not qubes related are because you chose to not set the group to 7 as well. A umask of 0077 would eliminate these problems. When it comes to qubes, I don't know what the problem was, and I can't find what the problem was in detail. So as I said, we are most likely clear apart from qubes. But I don't know if the problem with qubes was the umask value itself or the fact that we put files under |
|
monsieuremre:
> Really needed? How can core dumps still be created without that setting?
No. They can't be created. But disabling core dumps with all means possible is a better approach to not let any possibility of the user accidentally enabling them.
How would core dumps we accidentally enabled?
And then how would setting this prevent this issue?
|
|
Why is |
|
As for default umask, could we use libpam-umask package instead as Debian mentions in the link that you shared? That seems cleaner. /etc/profile.d seems hackish. Last resort only. It's hard to know in which situations it applies and when it doesn't in the various environments such as:
Check this out: |
|
https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/mkhomedir-security-misc uses |
https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/umask-security-misc |
|
As for umask, that seems to work. Please test and let me know if that resolves the umask part. |
|
That umask setting works for user and root but it has the same issue as before. Files created by root in /etc aren't readable by "others".
Maybe
Therefore I reverted my pam based implementation for now. |
|
Reverted the revert. Quote pam_umask man page.
Maybe that could fix the root issue. |
Does not work. Files created by root still unreadable by others.
Works as expected.
|
|
It might be possible to script Linux PAM config so pam_umask does not apply to root. |
since this causes permission issues in `/etc/` Kicksecure#151
Done. |
|
Readme was updated for pam_umask use. |
They wouldn't normally. But disabling them wherever possible is a net positive and brings no harm.
I don't understand how it's duplicated.
This is the expected funtionality. That's why we set it to 0027 or 0077. So that others can't read. I don't understand how this is a problem. Does it break anything? Root is arguably the most important user that should have this umask. |
Because core dump disabling is already disabled using the appropriate configuration files I see no benefit in doing it in /etc/profile.d again. Instead there's a bit harm:
It breaks reading config files in /etc for:
|
Permissions don't apply retroactively. So older files' permissions will stay the same. We can make exceptions for these files also for the future if they are countable, for example by manually granting read permission for others with the permission-hardener daemon. It is also an admin's responsibility to set the read permissions manually after creating configuration files. So manual stuff, no problem. Only the packages might be problematic. If these are too many to create exceptions for, we just stay with the current workaround. |
Retroactive is relative. Once the new umask for root enabled, and after another package gets installed, the umask hardening might apply.
An admin trying to harden / preconfigure for example /etc/firefox-esr or /etc/thunderbird will have no clue whatsoever that the config files will be readable by root only but not by the actual applications to be configured. Since these are graphical applications, there might be no error message. If lucky, there might be a warning or error message from starting the application from a terminal emulator.
It cannot be guestimated how many such cases exist. |
|
Hmm. Thinking. Yeah maybe. Current umask for everyone but root is already not that bad anyway. We can still add the coredump limit tho. I see no harm there. The use case of coredumps is really to my knowledge wastly limited to kernel development and debugging and stuff. Those people will figure how to disable coredumps if they choose to harden anyway, considering that would make their work harder. |
|
|
I don't think we should worry about that much. Coredumps are of no use on a daily driver. Debugging and development are the only cases where someone would want to enable it, which I say, these people probably won't do kernel development or debugging on their daily driver. It is true that it might be useful for debugging and development in a general sense that is not limited to the kernel, but I don't think it is far fetched to assume these people are in a position to re-enable coredumps themselves. |
Unfortunately that is a wrong assumption. I know, discussed similar things with skilled developers for C and whatnot but they would fail with the sysadmin part because that's a much different skill. Documentation exists on the internet but scattered. Hence, my development standard has always been that that is hardened should be documented with known ways on how to undo it. If even you cannot easily answer above questions in much more time than required to type it that means that it's already too difficult. The core dump might have been a slip through. Something I'll look into. Complete, clean, documented, reversible solutions are welcome. Otherwise incomplete, quick solutions with hardening only but without documentation and not easily reversible will take some time until I can complete them. |
Got it. Should not be difficult to document. |
Ergo, closing. |
Disabling coredumps and setting a secure umask value. Comments explain more in detail. I am really sorry for the many pull requests, this is the last one. I don't mean to spam the project. They are mostly really small but significant changes. I thought that it would be easier to manage for the maintainer if they are seperated.