Summary: | chsh doesn't work in enforcing mode ~amd64/selinux | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Amadeusz Sławiński <amade> |
Component: | Hardened | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | selinux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Amadeusz Sławiński
2012-01-30 23:03:44 UTC
I'm not that happy with the two obvious scenario's here: - allow chfn_t to manage shadow_t files (or even just write to them if that's all that was needed). After all, it should only update the passwd file. Sadly, it uses the /etc/.pwd.lock file as a locking file to ensure updates aren't crossing each other. But granting it access to shadow_t opens a path for more disclosure (or even modification of) which I really don't want to do. - make /etc/.pwd.lock an etc_t file instead of shadow_t. Although I don't know if there is a risk here, it strikes me that this file is explicitly marked as a shadow_t file in our policy. "Lowering" its type to etc_t *might* make it susceptible to race conditions from less trusted resources (which do have etc_t write privileges) Going to check with some other authorative sources on this one Checking upstream See http://oss.tresys.com/pipermail/refpolicy/2012-March/005027.html Ok, going to mark .pwd.lock as etc_t for now. In hardened-dev overlay (since 2012-04-11, forgot to update bugreport) You might need to restorecon /etc/.pwd.lock after updating the policies at first. In main tree, ~arch'ed Stable |