On Tue, Aug 24, 2021 at 12:00 PM Topi Miettinen <toiwoton@xxxxxxxxx> wrote: > > On 24.8.2021 15.47, Stephen Smalley wrote: > > Some history and a few observations. These are the common file > > permissions as declared in the common access vector blocks in the > > policy inherited by all the file classes and as defined as > > COMMON_FILE_PERMS in security/selinux/include/classmap.h. > > We used to have COMMON_FILE__READ, COMMON_FILE__WRITE, ... permission > > definitions as well but those went away with the migration to dynamic > > class/perm mapping and weren't being used in the code anyway; we have > > always just used FILE__x in the code when it was a common file > > permission. execmod was moved from being file-specific to being > > duplicated for chr_file to being taken into the common file perms > > (b424485abe2b16580a178b469917a7b6ee0c152a). open was moved to common > > file perms and the explicit per-class mapping dropped from the code in > > 49b7b8de46d293113a0a0bb026ff7bd833c73367. > > > > Before removing a permission from a class you need to ensure that the > > check can never fire. It isn't enough that the operation might not be > > implemented for the object; if the permission check can be reached > > then we either need the permission to remain or replicate the check > > against the object type before checking permission and return the same > > error as the underlying code ala ENOTSUP or whatever. > > Could there really be a case where a permission check for "execmod" > could be reachable for class "dir"? Executing on some strange file > system which does not distinguish files from directories? Probably not. I think it is only applicable to file, chr_file, and blk_file. That said I have been surprised before, e.g. https://lore.kernel.org/selinux/20170512164124.16981-1-sds@xxxxxxxxxxxxx/
