Custom LSM: getting a null pointer dereference when trying to access a task security blob

[Casey Schaufler]

On 1/24/2022 1:51 PM, Denis Obrezkov wrote:
>> I'm curious about the value provided by KeyLock.
>>
> disclaimer: it's mostly for educational purposes, a part of my phd studies.
>
> The main idea behind KeyLock is to be intuitive for an end-user. So, a
> user should be able to attach "lock" labels to files (objects). A file
> security context might look like: "label1(rw), label2(wx)"
> Also, a user should be able to attach "key" labels to tasks (subjects).
> So, the context of a task might look: "label5(r), label2(xt)"
>
> A subject will have access to an object if it has all the keys for all
> the locks:
>         Task (subj)     |     File (obj)         | Access provided
> -----------------------------------------------------------------------
>   lbl1(rw),lbl2(rx)     |    lbl1(rwx),lbl2(rwx) |  yes: r
>   lbl1(rw),lbl2(rwx)    |    lbl1(wx),lbl2(r)    |  no (see masks)
>   lbl1(rwx),lbl3(rwx)   |    lbl1(rwx),lbl2(rwx) |  no (no 'lbl2' key)
>
> As you can see, actions like r, w, x are also accounted. So, firstly, in
> order to provide access we should:
> 1. check that all "locks" have corresponding "keys"
> 2. logically summarize all permissions for each "key-lock" pair:
> from the first example above
> lbl1(rw) + lbl1(rwx) -> rw
> lbl2(rx) + lbl2(rwx) -> rx
> rw + rx -> r
>
> So, with that system we can get rig of a rules file. Also, there is a
> chance that it would be easier to use for non-IT people.

You may want to have a closer look at AppArmor before you go too much
further. One of the most significant usage issues with Smack and SELinux
is the curious relationship between filesystem objects and pathnames.
Your approach looks interesting as far as it goes, but to be useful
you might want to address the age old problem of what happens when
/etc/passwd is modified by copy+replace.

> P.S. I know that it is possible to do similar things in SMACK, but for
> educational purposes I decided to implement it in kernel code.

Smack and SELinux are designed to enforce policy on all objects.
There could well be a place for a system that has a different
approach.

> P.P.S. I tried to do it using SELinux and its policy languages but it
> was too complicated for me.

Yes, the granularity gremlins got hold of SELinux in about 2005 and
have never looked back. There are people who write policy, and who
say it's not hard, but all I can think is that their minds work differently
from mine. That, or they're just smarter than I.