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

[Denis Obrezkov]

> 
> 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.

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.

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

-- 
Regards, Denis Obrezkov