On 2023/10/21 23:11, Casey Schaufler wrote: >> If the system call returning LSM ID value for SELinux but does not tell >> the caller of that system call whether a specific action might be permitted, >> what information does LSM ID value tell? > > It tells the caller that the LSM is active on the system. That's it. > Just like reading /sys/kernel/security/lsm. Then, the The calling application can use this list determine what LSM specific actions it might take. That might include choosing an output format, determining required privilege or bypassing security module specific behavior. part should be removed from the description. Instead, the description should emphasis that the numeric LSM ID values are there in order to allow identifying what LSM modules are active without interpreting string LSM names in /sys/kernel/security/lsm . >> What does "choosing an output format", "determining required privilege", >> "bypassing security module specific behavior" mean? How can they choose >> meaningful output format, determine appropriate privilege, bypass security >> module specific behavior (if the only information the caller can know from >> the LSM ID value were what LSMs are enabled) ? > > If Smack and SELinux not enabled on the system there is no point in > setting up a netlabel configuration, for example. I know nothing about netlabel. But can userspace make such assumption from this granularity? For example, if TOMOYO and AppArmor start supporting netlabel configuration, your assumption If Smack and SELinux not enabled on the system there is no point in setting up a netlabel configuration becomes no longer true. It is also possible that a new LSM implementation obtains an LSM ID for that LSM, and starts supporting netlabel configuration some timer later. I don't know if we come to the point where we can enable SELinux and Smack at the same time. But when it becomes possible to enable SELinux and Smack at the same time, the userspace might have already written code based on current situation that netlabel configuration are exclusive. Then, someday starting to return both LSM ID for SELinux and LSM ID for Smack might confuse userspace. Thus, it might be safe to determine what LSMs are active from the LSM ID values returned from the system call. But it is not safe to assume what functionality is active (e.g. netlabel configuration is interpreted) from the LSM ID values returned from the system call. If you want to allow userspace to make such assumption using the system call, the granularity the system call returns needs to be what access control mechanism (not only LSM modules but also eBPF-based access control mechanisms) hooks which LSM hooks. More information than interpreting string LSM names in /sys/kernel/security/lsm will be needed. > >>> I wish we could stop people from saying "BPF-based LSM". BPF is the LSM. The >>> eBPF programs that implement a "policy" are NOT a LSM. There needs to be a >>> name for that, but LSM is not it. >> My understanding is that "BPF is not an LSM module but infrastructure for using >> LSM hooks". > > As BPF is implemented as a LSM I suggest your statement is incorrect. Enumerating only LSM modules are not useful. "ID for access control mechanisms that can be controlled via LSM hooks" will be needed. > >> >> The patch description lacks relationship between LSM ID value and data. >> In other words, why LSM ID values are needed (and are useful for doing what). >> If the only information the caller can know from the LSM ID value were >> what LSMs are enabled (i.e. the content of /sys/kernel/security/lsm ), why >> bother to use LSM ID values? (Yes, integer comparison is faster than string >> comparison. But that is not enough justification for not allowing out-of-tree >> LSMs and eBPF-based access control mechanisms to have stable LSM ID values.) >> I conclude that LSM ID values are pointless and are NOT needed.
