disable enforcement of user being in group sudo
adrelanos opened this issue · comments
Since we have modified
home_folder_access_rights_lockdownto work for all users with all usernames all the time, I don't see any reason to require the user to have a useruserin 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 #136 (comment)
Since we have modified
home_folder_access_rights_lockdownto work for all users with all usernames all the time, I don't see any reason to require the user to have a useruserin 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.
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.
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.
- It does not break the package.
- It only aborts package installation unless environment variable
SECURITY_MISC_INSTALL=forceis set which is documented in the error message. This is because without such a warning there is a high chance the user could be locked out.
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":
Not sure what could be improved in security-misc but if this is still an issue please explain and re-open.