On Thu, 2011-07-14 at 23:23 +1000, Russell Coker wrote: > On Thu, 14 Jul 2011, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > Don't reuse the kernel classes/permissions please. I know we've done > > that in e.g. crond in the past, but it conflates their purpose; > > The crond operation is to ask the kernel what could happen if the crontab > spool file was treated as an executable, and then apply the resulting context > for executing the commands that it contains. Yes, IIRC, that was my idea. > While this is not obvious to a SE Linux newbie, it makes sense and it closely > matches the ancient crond code for checking UIDs for the Unix permission > parts. > > While making the operation more obvious to newbies does offer some benefits > (including security benefits by avoiding mistakes), I can't think of a good > way of achieving such a goal. > > If we were to start from the Vixie-cron base and write entirely new SE Linux > patches and policy without any legacy today how do you think we would do it > better? In retrospect, I think it would have been cleaner to have defined a unique class/perm for this purpose. Both in order to cleanly delineate the kernel classes/permissions from userspace ones and to make clear the semantic difference between an execve of a file and running a cron job from a configuration file. > systemd has to use labels on files for all variants of the proposed design so > classes aren't an option. It is fine for systemd to use a file label as the object security context if that is the granularity at which we want to control the operations, but systemd can still define and use its own classes and permissions for the permission checks on its operations. In a similar manner, dbusd is using the security context of the destination process as the object security context for its check, yet it defines its own class and permissions for those checks. And of course all of the userspace object managers are using the process context as the subject/source context. > Once we get role support in the filesystem code (how long will that take?) we > could use role labels to determine which roles can execute the daemon start > scripts. But it would still surely end up with systemd just doing a check of > whether the context of systemctl permits executing the /etc/init.d script in > question. > -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
