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

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

[Denis Obrezkov]

Hello,

I am writing a small LSM similar to SMACK. I've wrote a task blob init hook:

static void init_task_keylock(struct task_keylock *tsp, struct
keylock_known *task, struct keylock_known *forked)
{
        tsp->kl_task = task;
        tsp->kl_forked = forked;
}

I predefined one label for the initial task (similar to SMACK's hat,
floor, etc):

struct keylock_known keylock_known_system = {
        .label          = "system\n",
        .kl_mask        = 7,
};

and I can see that as in SMACK I can get the label from the initial task
into the inodes:

static int keylock_inode_alloc_security(struct inode *inode)
{
        struct keylock_known *skp = kl_of_current();
        pr_info("KeyLock: skp->label:%s\n", skp->label);
        init_inode_keylock(inode, skp);
        return 0;
}

But after few successful reads I get the kernel null page dereference error:

[    0.193868] Mount-cache hash table entries: 8192 (order: 4, 65536
bytes, linear)
[    0.194860] Mountpoint-cache hash table entries: 8192 (order: 4,
65536 bytes, linear)
[    0.195883] KeyLock: skp->label:system
[    0.195883]
[    0.196847] KeyLock: skp->label:system
[    0.196847]
[    0.197844] KeyLock: skp->label:system
[    0.197844]
[    0.198920] KeyLock: skp->label:system
[    0.198920]
[    0.199958] x86/cpu: User Mode Instruction Prevention (UMIP) activated
[    0.200911] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[    0.201825] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[    0.202829] Spectre V1 : Mitigation: usercopy/swapgs barriers and
__user pointer sanitization
[    0.203825] Spectre V2 : Mitigation: Full generic retpoline
[    0.204824] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling
RSB on context switch
[    0.205824] Spectre V2 : Enabling Restricted Speculation for firmware
calls
[    0.206825] Spectre V2 : mitigation: Enabling conditional Indirect
Branch Prediction Barrier
[    0.207825] Speculative Store Bypass: Mitigation: Speculative Store
Bypass disabled via prctl and seccomp
[    0.208828] SRBDS: Unknown: Dependent on hypervisor status
[    0.209783] MDS: Mitigation: Clear CPU buffers
[    0.217907] Freeing SMP alternatives memory: 40K
[    0.218822] smpboot: CPU0: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
(family: 0x6, model: 0x45, stepping: 0x1)
[    0.218961] Performance Events: Haswell events, Intel PMU driver.
[    0.219839] ... version:                2
[    0.220665] ... bit width:              48
[    0.220827] ... generic registers:      4
[    0.221660] ... value mask:             0000ffffffffffff
[    0.221827] ... max period:             000000007fffffff
[    0.222636] ... fixed-purpose events:   3
[    0.222827] ... event mask:             000000070000000f
[    0.223896] rcu: Hierarchical SRCU implementation.
[    0.224993] smp: Bringing up secondary CPUs ...
[    0.225771] smp: Brought up 1 node, 1 CPU
[    0.225828] smpboot: Max logical packages: 1
[    0.226536] smpboot: Total of 1 processors activated (4789.13 BogoMIPS)
[    0.227006] BUG: kernel NULL pointer dereference, address:
0000000000000030
[    0.227823] #PF: supervisor read access in kernel mode
[    0.227823] #PF: error_code(0x0000) - not-present page
[    0.227823] PGD 0 P4D 0
[    0.227823] Oops: 0000 [#1] SMP PTI
[    0.227823] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.17+ #4
[    0.227823] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.13.0-1ubuntu1.1 04/01/2014
[    0.227823] RIP: 0010:keylock_inode_alloc_security+0x2b/0x48
[    0.227823] Code: 65 48 8b 04 25 00 6d 01 00 53 48 8b 90 58 06 00 00
48 89 fb 48 c7 c7 6a 7e 23 88 48 63 05 54 2e 80 00 48 8b 52 78 48 8b 2c
02 <48> 8b 75 30 e8 72 66 ff ff 48 63 05 44 29
[    0.227823] RSP: 0000:ffffb50b80013d50 EFLAGS: 00010282
[    0.227823] RAX: 0000000000000000 RBX: ffffa2bc80144320 RCX:
0000000000000020
[    0.227823] RDX: ffffa2bc8005b0c0 RSI: ffffffff87367cbf RDI:
ffffffff88237e6a
[    0.227823] RBP: 0000000000000000 R08: 0000000000000020 R09:
ffffa2bc8010b080
[    0.227823] R10: 8e89d572bb4b3d14 R11: 52cbeeedbf187f36 R12:
ffffa2bc80144320
[    0.227823] R13: ffffa2bc80144488 R14: 0000000000000000 R15:
ffffa2bc80149000
[    0.227823] FS:  0000000000000000(0000) GS:ffffa2bcbbc00000(0000)
knlGS:0000000000000000
[    0.227823] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.227823] CR2: 0000000000000030 CR3: 000000001b60c001 CR4:
0000000000170ef0
[    0.227823] Call Trace:
[    0.227823]  security_inode_alloc+0x40/0x80
[    0.227823]  ? _cond_resched+0x10/0x20
[    0.227823]  inode_init_always+0xd4/0x1e0
[    0.227823]  alloc_inode+0x2b/0x90
[    0.227823]  new_inode_pseudo+0x7/0x50
[    0.227823]  new_inode+0xe/0x30
[    0.227823]  shmem_get_inode+0x59/0x240
[    0.227823]  ? shmem_put_super+0x50/0x50
[    0.227823]  shmem_fill_super+0x1e4/0x230
[    0.227823]  vfs_get_super+0x74/0x100
[    0.227823]  vfs_get_tree+0x20/0xb0
[    0.227823]  ? shmem_parse_options+0x84/0xc0
[    0.227823]  fc_mount+0x9/0x30
[    0.227823]  vfs_kern_mount.part.0+0x6c/0x80
[    0.227823]  devtmpfs_init+0x47/0x149
[    0.227823]  driver_init+0x5/0x28
[    0.227823]  kernel_init_freeable+0xc4/0x1d3
[    0.227823]  ? rest_init+0xa4/0xa4
[    0.227823]  kernel_init+0x5/0xfc
[    0.227823]  ret_from_fork+0x22/0x30
[    0.227823] Modules linked in:
[    0.227823] CR2: 0000000000000030
[    0.227823] ---[ end trace 63f588023014db8e ]---
[    0.227823] RIP: 0010:keylock_inode_alloc_security+0x2b/0x48

It seems that something happens after smpboot.I assumed that the pointer
to the initial task struct would be copied to every child task. And that
stuct keylock_known_system would be always accessible. What could be my
mistake?

-- 
Regards, Denis Obrezkov

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

[Casey Schaufler]

On 1/23/2022 7:47 AM, Denis Obrezkov wrote:
> Hello,
>
> I am writing a small LSM similar to SMACK. I've wrote a task blob init hook:
>
> static void init_task_keylock(struct task_keylock *tsp, struct
> keylock_known *task, struct keylock_known *forked)
> {
>          tsp->kl_task = task;
>          tsp->kl_forked = forked;
> }
>
> I predefined one label for the initial task (similar to SMACK's hat,
> floor, etc):
>
> struct keylock_known keylock_known_system = {
>          .label          = "system\n",
>          .kl_mask        = 7,
> };
>
> and I can see that as in SMACK I can get the label from the initial task
> into the inodes:
>
> static int keylock_inode_alloc_security(struct inode *inode)
> {
>          struct keylock_known *skp = kl_of_current();
>          pr_info("KeyLock: skp->label:%s\n", skp->label);
>          init_inode_keylock(inode, skp);
>          return 0;
> }
>
> But after few successful reads I get the kernel null page dereference error:

There's nowhere near enough information here to identify what's
going wrong here. Is the KeyLock code otherwise a copy of Smack?
Have you registered KeyLock correctly with the infrastructure?

>
> [    0.193868] Mount-cache hash table entries: 8192 (order: 4, 65536
> bytes, linear)
> [    0.194860] Mountpoint-cache hash table entries: 8192 (order: 4,
> 65536 bytes, linear)
> [    0.195883] KeyLock: skp->label:system
> [    0.195883]
> [    0.196847] KeyLock: skp->label:system
> [    0.196847]
> [    0.197844] KeyLock: skp->label:system
> [    0.197844]
> [    0.198920] KeyLock: skp->label:system
> [    0.198920]
> [    0.199958] x86/cpu: User Mode Instruction Prevention (UMIP) activated
> [    0.200911] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
> [    0.201825] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
> [    0.202829] Spectre V1 : Mitigation: usercopy/swapgs barriers and
> __user pointer sanitization
> [    0.203825] Spectre V2 : Mitigation: Full generic retpoline
> [    0.204824] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling
> RSB on context switch
> [    0.205824] Spectre V2 : Enabling Restricted Speculation for firmware
> calls
> [    0.206825] Spectre V2 : mitigation: Enabling conditional Indirect
> Branch Prediction Barrier
> [    0.207825] Speculative Store Bypass: Mitigation: Speculative Store
> Bypass disabled via prctl and seccomp
> [    0.208828] SRBDS: Unknown: Dependent on hypervisor status
> [    0.209783] MDS: Mitigation: Clear CPU buffers
> [    0.217907] Freeing SMP alternatives memory: 40K
> [    0.218822] smpboot: CPU0: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> (family: 0x6, model: 0x45, stepping: 0x1)
> [    0.218961] Performance Events: Haswell events, Intel PMU driver.
> [    0.219839] ... version:                2
> [    0.220665] ... bit width:              48
> [    0.220827] ... generic registers:      4
> [    0.221660] ... value mask:             0000ffffffffffff
> [    0.221827] ... max period:             000000007fffffff
> [    0.222636] ... fixed-purpose events:   3
> [    0.222827] ... event mask:             000000070000000f
> [    0.223896] rcu: Hierarchical SRCU implementation.
> [    0.224993] smp: Bringing up secondary CPUs ...
> [    0.225771] smp: Brought up 1 node, 1 CPU
> [    0.225828] smpboot: Max logical packages: 1
> [    0.226536] smpboot: Total of 1 processors activated (4789.13 BogoMIPS)
> [    0.227006] BUG: kernel NULL pointer dereference, address:
> 0000000000000030
> [    0.227823] #PF: supervisor read access in kernel mode
> [    0.227823] #PF: error_code(0x0000) - not-present page
> [    0.227823] PGD 0 P4D 0
> [    0.227823] Oops: 0000 [#1] SMP PTI
> [    0.227823] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.17+ #4
> [    0.227823] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.13.0-1ubuntu1.1 04/01/2014
> [    0.227823] RIP: 0010:keylock_inode_alloc_security+0x2b/0x48
> [    0.227823] Code: 65 48 8b 04 25 00 6d 01 00 53 48 8b 90 58 06 00 00
> 48 89 fb 48 c7 c7 6a 7e 23 88 48 63 05 54 2e 80 00 48 8b 52 78 48 8b 2c
> 02 <48> 8b 75 30 e8 72 66 ff ff 48 63 05 44 29
> [    0.227823] RSP: 0000:ffffb50b80013d50 EFLAGS: 00010282
> [    0.227823] RAX: 0000000000000000 RBX: ffffa2bc80144320 RCX:
> 0000000000000020
> [    0.227823] RDX: ffffa2bc8005b0c0 RSI: ffffffff87367cbf RDI:
> ffffffff88237e6a
> [    0.227823] RBP: 0000000000000000 R08: 0000000000000020 R09:
> ffffa2bc8010b080
> [    0.227823] R10: 8e89d572bb4b3d14 R11: 52cbeeedbf187f36 R12:
> ffffa2bc80144320
> [    0.227823] R13: ffffa2bc80144488 R14: 0000000000000000 R15:
> ffffa2bc80149000
> [    0.227823] FS:  0000000000000000(0000) GS:ffffa2bcbbc00000(0000)
> knlGS:0000000000000000
> [    0.227823] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.227823] CR2: 0000000000000030 CR3: 000000001b60c001 CR4:
> 0000000000170ef0
> [    0.227823] Call Trace:
> [    0.227823]  security_inode_alloc+0x40/0x80
> [    0.227823]  ? _cond_resched+0x10/0x20
> [    0.227823]  inode_init_always+0xd4/0x1e0
> [    0.227823]  alloc_inode+0x2b/0x90
> [    0.227823]  new_inode_pseudo+0x7/0x50
> [    0.227823]  new_inode+0xe/0x30
> [    0.227823]  shmem_get_inode+0x59/0x240
> [    0.227823]  ? shmem_put_super+0x50/0x50
> [    0.227823]  shmem_fill_super+0x1e4/0x230
> [    0.227823]  vfs_get_super+0x74/0x100
> [    0.227823]  vfs_get_tree+0x20/0xb0
> [    0.227823]  ? shmem_parse_options+0x84/0xc0
> [    0.227823]  fc_mount+0x9/0x30
> [    0.227823]  vfs_kern_mount.part.0+0x6c/0x80
> [    0.227823]  devtmpfs_init+0x47/0x149
> [    0.227823]  driver_init+0x5/0x28
> [    0.227823]  kernel_init_freeable+0xc4/0x1d3
> [    0.227823]  ? rest_init+0xa4/0xa4
> [    0.227823]  kernel_init+0x5/0xfc
> [    0.227823]  ret_from_fork+0x22/0x30
> [    0.227823] Modules linked in:
> [    0.227823] CR2: 0000000000000030
> [    0.227823] ---[ end trace 63f588023014db8e ]---
> [    0.227823] RIP: 0010:keylock_inode_alloc_security+0x2b/0x48
>
> It seems that something happens after smpboot.I assumed that the pointer
> to the initial task struct would be copied to every child task. And that
> stuct keylock_known_system would be always accessible. What could be my
> mistake?
>

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

[Denis Obrezkov]

> 
> There's nowhere near enough information here to identify what's
> going wrong here. Is the KeyLock code otherwise a copy of Smack?
> Have you registered KeyLock correctly with the infrastructure?
> 
Yes, right now the only difference is that I don't have a single
repository for all labels. For each task/inode I store only a pointer to
a head of a list of its own labels. I want to store pointers in
creds->security and inode->i_security. So, basically each subject will
have its own repository of (its) labels.
Right now, I have only one security context which is defined in my .c file:
struct keylock_known keylock_known_system = {
        .label          = "system\n",
        .kl_mask        = 7,
};

First tasks receive the pointer to this structure and I can see that the
pointer value for them is non-zero. But later I can see that other tasks
in keylock_inode_alloc_security have zero pointers,
I have two hypotheses. First is that my keylock_known_system is not
visible to other tasks (though it is initialized in a global scope of my
.c file). Second is that I didn't implement some crucial hooks and a new
task is created without a label. I have implemented those hooks:


static struct security_hook_list keylock_hooks[] __lsm_ro_after_init = {
        LSM_HOOK_INIT(inode_alloc_security, keylock_inode_alloc_security),
        LSM_HOOK_INIT(inode_init_security, keylock_inode_init_security),
        LSM_HOOK_INIT(task_to_inode, keylock_task_to_inode),
        LSM_HOOK_INIT(cred_transfer, keylock_cred_transfer),
        LSM_HOOK_INIT(cred_alloc_blank, keylock_cred_alloc_blank),

};


And I initialized my KeyLock LSM in a way similar to that of SMACK.

--
Regards, Denis Obrezkov

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

[Denis Obrezkov]

It seems I didn't implement cred_prepare and it was crucial.

On 23.01.22 20:58, Denis Obrezkov wrote:

> I have two hypotheses. First is that my keylock_known_system is not
> visible to other tasks (though it is initialized in a global scope of my
> .c file). Second is that I didn't implement some crucial hooks and a new
> task is created without a label. I have implemented those hooks:
> 
> 
> static struct security_hook_list keylock_hooks[] __lsm_ro_after_init = {
>         LSM_HOOK_INIT(inode_alloc_security, keylock_inode_alloc_security),
>         LSM_HOOK_INIT(inode_init_security, keylock_inode_init_security),
>         LSM_HOOK_INIT(task_to_inode, keylock_task_to_inode),
>         LSM_HOOK_INIT(cred_transfer, keylock_cred_transfer),
>         LSM_HOOK_INIT(cred_alloc_blank, keylock_cred_alloc_blank),
> 
> };
> 
> 
> And I initialized my KeyLock LSM in a way similar to that of SMACK.
> 
> --
> Regards, Denis Obrezkov

-- 
Regards, Denis Obrezkov

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

[Casey Schaufler]

On 1/24/2022 1:56 AM, Denis Obrezkov wrote:
> It seems I didn't implement cred_prepare and it was crucial.

Smack uses a global list for a number of reasons, one of
which is that you need to hang the rules off of something.
Also, lifetime management of the data can be tricky. Finally,
if every instance of the label "IAmALabel" is stored in the
same place you never have to do a strcmp() to determine if
two labels match.

I'm curious about the value provided by KeyLock.

>
> On 23.01.22 20:58, Denibs Obrezkov wrote:
>
>> I have two hypotheses. First is that my keylock_known_system is not
>> visible to other tasks (though it is initialized in a global scope of my
>> .c file). Second is that I didn't implement some crucial hooks and a new
>> task is created without a label. I have implemented those hooks:
>>
>>
>> static struct security_hook_list keylock_hooks[] __lsm_ro_after_init = {
>>          LSM_HOOK_INIT(inode_alloc_security, keylock_inode_alloc_security),
>>          LSM_HOOK_INIT(inode_init_security, keylock_inode_init_security),
>>          LSM_HOOK_INIT(task_to_inode, keylock_task_to_inode),
>>          LSM_HOOK_INIT(cred_transfer, keylock_cred_transfer),
>>          LSM_HOOK_INIT(cred_alloc_blank, keylock_cred_alloc_blank),
>>
>> };
>>
>>
>> And I initialized my KeyLock LSM in a way similar to that of SMACK.
>>
>> --
>> Regards, Denis Obrezkov

Re: 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

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