On Mon, Jun 1, 2020 at 3:29 AM Chirantan Ekbote <chirantan@xxxxxxxxxxxx> wrote: > > Normally a process needs CAP_SYS_ADMIN in the namespace that mounted a > particular filesystem in order to set a security xattr. However, this > restriction is relaxed for the security.selinux xattr: the file owner > or a process with CAP_FOWNER in its namespace may set this attribute. > > Apply this relaxed restriction to the security.sehash xattr as well. > Since this xattr is mainly a performance optimization when labeling > files recursively it shouldn't have stricter requirements than setting > the selinux xattr in the first place. First, setting either security.<non-selinux> or security.selinux has an additional MAC check beyond the DAC/capability check; in the former case there is the FILE__SETATTR check and in the latter there are the FILE__RELABELFROM/TO checks. We need to preserve some kind of SELinux permission check here. Second, security.sehash logic in userspace was introduced by Android in its libselinux fork and then copied in upstream logic. I'm not sure Android wants to relax the current requirement for CAP_SYS_ADMIN - I have copied them above. A possible concern is that an unprivileged process could disable the relabeling of a part of the tree that it owns upon an upgrade, which could have unexpected consequences.
