search

Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
https://www.kicksecure.com/wiki/Impressum
Other
518 stars 51 forks source link

disable enforcement of user being in group sudo #155

Closed adrelanos closed 5 months ago

adrelanos commented 1 year ago

Since we have modified home_folder_access_rights_lockdown to work for all users with all usernames all the time, I don't see any reason to require the user to have a user user in the sudo group. This rule is still enforced on package install. This could and should be removed I think. Is there any other reason to keep this condition that I do not know of?

Originally posted by @monsieuremre in https://github.com/Kicksecure/security-misc/issues/136#issuecomment-1789537990

adrelanos commented 1 year ago

Since we have modified home_folder_access_rights_lockdown to work for all users with all usernames all the time, I don't see any reason to require the user to have a user user in the sudo group. This rule is still enforced on package install. This could and should be removed I think. Is there any other reason to keep this condition that I do not know of?

home_folder_access_rights_lockdown is really unrelated.

Due to https://github.com/Kicksecure/security-misc#root-access-restrictions the user would be locked out without any root access available except for rescue, emergency shell or live boot.

By setting SECURITY_MISC_INSTALL=force, this check can already be disabled if someone wanted a complete lockdown where no user is in group sudo.

For other options to gain root if these are testable, we could consider testing for these too and allow installation (that is not abort due to user lockout risk).

The check isn't hardcoded to user user. Any user name would work. It's generic.

adrelanos commented 1 year ago

related: https://forums.whonix.org/t/replace-sudo-with-doas/17482

monsieuremre commented 1 year ago

The check isn't hardcoded to user user. Any user name would work. It's generic.

Even if that is the case, the warning messages on package install imply otherwise. Those should change then. And also, having no user in sudo should not break any functionality in the package. We have to just prompt this as a recommendation, but not enforce it. And even if we choose to enforce this regardless, we might as well lock the root account.

adrelanos commented 1 year ago

The check isn't hardcoded to user user. Any user name would work. It's generic.

Even if that is the case, the warning messages on package install imply otherwise.

It says:

No user is a member of group 'sudo'. Installation aborted.

It does not say "user 'user' isn't a member of group 'sudo'."

I've updated https://www.kicksecure.com/wiki/Template:Prerequisites just now to make it more generic (https://www.kicksecure.com/wiki/security-misc#install uses it.) as well as updated debian/security-misc.preinstall message to clarify this. Other output clarification modifications can be considered if still not sufficient.

And also, having no user in sudo should not break any functionality in the package.

We have to just prompt this as a recommendation, but not enforce it.

Inventing a prompt using debconf is difficult for me. And we still wouldn't have a good default action other than the current one when run non-interactively (during a build script, without a keyboard connected).

And even if we choose to enforce this regardless, we might as well lock the root account.

Root account is locked in Kicksecure but not by security-misc. dist-base-files debian/dist-base-files.postinst locks the root account. Not doing from security-misc due to these issues.

Since a non-issue in Kicksecure, this perfection of security-misc is "patches welcome":

adrelanos commented 5 months ago

Not sure what could be improved in security-misc but if this is still an issue please explain and re-open.