On Fri, Jul 26, 2019 at 10:05 AM Martin Townsend
<mtownsend1973@xxxxxxxxx> wrote:
>
> On Thu, Jul 25, 2019 at 8:44 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> >
> > On 7/25/2019 8:07 AM, Martin Townsend wrote:
> > > On Mon, Jul 22, 2019 at 10:35 PM Martin Townsend
> > > <mtownsend1973@xxxxxxxxx> wrote:
> >
> > I'm adding the smack-discuss list to the thread.
> >
> > >> On Mon, Jul 22, 2019 at 10:23 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> > >>> On 7/22/2019 1:19 PM, Martin Townsend wrote:
> > >>>> Hi Casey
> > >>>>
> > >>>> Thank you for the swift reply.
> > >>>>
> > >>>> On Mon, Jul 22, 2019 at 5:25 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> > >>>>> On 7/22/2019 1:03 AM, Martin Townsend wrote:
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> One of our developers has reported the following audit log entry when
> > >>>>>> trying to add a key to the kernel's keyring when SMACK is enabled:
> > >>>>>>
> > >>>>>> Jul 9 09:33:23 mach-cw-rnet-ppm-1840 user.notice kernel: audit:
> > >>>>>> type=1400 audit(1562664803.960:12): lsm=SMACK fn=smack_key_permission
> > >>>>>> action=denied subject="programmingapp" object="_" requested=w pid=905
> > >>>>>> comm="programmingapp" key_serial=98475196 key_desc="_ses"
> >
> > Why does programmingapp need write access to the key "_ses" ?
> > Knowing this may help identify options.
> >
> > >>>>> The Smack label on a key is set when the key is created,
> > >>>>> and is set to the label of the process that created it.
> > >>>> I'll have to check but I thought that the programmingapp process from
> > >>>> the audit message above was trying to create the key, the dev team
> > >>>> were reporting that the add_key syscall was failing the SMACK access
> > >>>> check. This raises another question, we currently compile in several
> > >>>> root Certificates into the kernel, would these get a SMACK label? and
> > >>>> if so would this be '_'?
> > >>> Yes, that could easily be what's happening here.
> > >>>
> > >>> What does a "compiled in" certificate look like?
> > >> It's a PEM file of concatenated certificates that you copy into the
> > >> certs directory I think and then set the following in the kernel
> > >> configuration (in this example we have a file called
> > >> builtin-trusted.pem)
> > >> CONFIG_SYSTEM_TRUSTED_KEYRING=y
> > >> CONFIG_SYSTEM_TRUSTED_KEYS="certs/builtin-trusted.pem"
> > >>
> > >> I'm assuming that the public keys contained in the certificates are
> > >> added to the kernels trusted keying automatically during boot.
> > >>
> > >>>>>> I had a quick look through the code in smack_lsm.c but can't see how
> > >>>>>> I'm supposed to set a SMACK label for keys or keyrings. Is it
> > >>>>>> possible and if so how?
> > >>>>> There is currently no way to change the Smack label on a key.
> > >>>>>
> > >>>>>> We are running a 4.9 Kernel with not much
> > >>>>>> chance of upgrading as it's a vendor kernel (linux-imx). As it's an
> > >>>>>> embedded system we are happy to hard code the SMACK labels into the
> > >>>>>> kernel if this is possible?
> > >>>>> In smack_key_alloc() change
> > >>>>>
> > >>>>> key->security = skp;
> > >>>>>
> > >>>>> to
> > >>>>> key->security = &smack_known_star;
> > >>>>>
> > >>>>> and all keys will have the star ("*") label, which
> > >>>>> grants everyone access to them. Not the best solution
> > >>>>> long term, but it should get you by.
> > >>>> They are currently adding a rule 'programmingapp _ rw' so I think this
> > >>>> would be an upgrade :)
> > >>>> Could I go one further and have something like?
> > >>>> #ifdef CONFIG_KEYS
> > >>>>
> > >>>> +static struct smack_known smack_known_keymaster = {
> > >>>> + .smk_known = "keymaster",
> > >>>> + .smk_secid = 9,
> > >>>> +};
> > >>>> +
> > >>>> /**
> > >>>> * smack_key_alloc - Set the key security blob
> > >>>> * @key: object
> > >>>> @@ -4327,9 +4332,7 @@ static void smack_inet_csk_clone(struct sock *sk,
> > >>>> static int smack_key_alloc(struct key *key, const struct cred *cred,
> > >>>> unsigned long flags)
> > >>>> {
> > >>>> - struct smack_known *skp = smk_of_task(cred->security);
> > >>>> -
> > >>>> - key->security = skp;
> > >>>> + key->security = &smack_known_keymaster;
> > >>>> return 0;
> > >>>> }
> > >>>>
> > >>>> or is this just asking for trouble
> > >>> That would be even better. Be sure to add smack_known_keymaster
> > >>> to the list of known labels, just like smack_known_floor and
> > >>> friends are.
> > >> Thank you, I didn't spot that.
> > >>
> > >>>>>> or is it set to '_' by design and we
> > >>>>>> should add the key whilst the process is a privileged state before the
> > >>>>>> SMACK label for the process has been set?
> > >>>>> If you can run the program that creates the key with a label
> > >>>>> other than floor ("_"), perhaps "keymaster", the key would be
> > >>>>> labeled keymaster, and you could create access rules like
> > >>>> I will get some more information on how they are creating the keys as
> > >>>> I thought the process creating the keys was labelled "programmingapp"
> > >>>> so the key in theory should be labelled "programmingapp". And looking
> > >>>> at the smack_key_alloc function mentioned previously it definitely
> > >>>> looks like it should have. I'll see if I can get them to create some
> > >>>> test code and debug why this isn't happening.
> > >>>> Thanks again for your help.
> > >>>>
> > >>>>> programmingapp keymaster rw
> > >>>>>
> > >>>>>
> > >>>>>> Many Thanks,
> > >>>>>> Martin.
> > > I created the keymaster label for all keys and I also had to add a
> > > rule of "_ keymaster rw" so that the kernel could setup the built-in
> > > trusted keyring and it boots fine but then we are seeing lots of
> > > processes failing with what looks like integrity checks and then
> > > messages like
> > >
> > > Jul 19 10:11:15 mach-cw-rnet-ppm-1840 audit[1572]: AVC lsm=SMACK
> > > fn=smack_key_permission action=denied subject="ubihealthd"
> > > object="keymaster" labels_differ pid=1572 comm="(ihealthd)"
> > > key_serial=20092166 key_desc=".ima_blacklist"
> > >
> > > Jul 19 10:11:15 mach-cw-rnet-ppm-1840 audit[1572]: AVC lsm=SMACK
> > > fn=smack_key_permission action=denied subject="ubihealthd"
> > > object="keymaster" labels_differ pid=1572 comm="(ihealthd)"
> > > key_serial=694943947 key_desc=".evm"
> >
> > Again, what is ubihealthd doing that it needs access to keys?
> >
> > >
> > > so I'm guessing that this means with my change I would have to give
> > > every process that reads the root filesystem a rule for keymaster as
> > > the main root filesystem is signed with IMA/EVM. The default of '_'
> > > I'm guessing would have the same effect and we would have to create a
> > > rule for floor for every process? I'm not sure what to do next except
> > > if we can somehow identify the ima/evm key and give this the '*'
> > > label. For the moment we are going to assign all keys '*' so we can
> > > proceed. I just thought I would report our findings and wondered if
> > > anyone had any ideas?
>
> I was asking the same questions :) so I put a dump_stack and outputted
> the description of the keys in smack_key_permission to find out.
>
> It looks like it is IMA. From the log file you can see that when a
> file is accessed from any process (ubihealthd was just one of them but
> literally every process does this)
>
> I'll pick on ubihealthd, I scanned through the source code and I can't
> see it using keys directly but it does write out a stats file.
>
> When the process starts up there is a quite a bit of interaction with
> the _ses and invocation_id keyrings
>
> CPU: 0 PID: 353 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803df864>]
> (lookup_user_key+0x144/0x500)
> [<803df864>] (lookup_user_key) from [<803dd410>] (SyS_add_key+0xd0/0x210)
> [<803dd410>] (SyS_add_key) from [<80107dfc>] (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=_ses
>
> CPU: 0 PID: 353 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803db9bc>]
> (key_create_or_update+0x190/0x38c)
> [<803db9bc>] (key_create_or_update) from [<803dd444>] (SyS_add_key+0x104/0x210)
> [<803dd444>] (SyS_add_key) from [<80107dfc>] (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=_ses
>
> CPU: 0 PID: 353 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803dcb14>]
> (keyring_search_aux+0x80/0x130)
> [<803dcb14>] (keyring_search_aux) from [<803df400>]
> (search_my_process_keyrings+0xd4/0x194)
> [<803df400>] (search_my_process_keyrings) from [<803df4e4>]
> (search_process_keyrings+0x24/0x10c)
> [<803df4e4>] (search_process_keyrings) from [<803dfa78>]
> (lookup_user_key+0x358/0x500)
> [<803dfa78>] (lookup_user_key) from [<803de2cc>] (keyctl_setperm_key+0x24/0xa4)
> [<803de2cc>] (keyctl_setperm_key) from [<80107dfc>]
> (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=_ses
>
> CPU: 0 PID: 353 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803dc464>]
> (keyring_search_iterator+0xa0/0xf0)
> [<803dc464>] (keyring_search_iterator) from [<803dc674>]
> (search_nested_keyrings+0x1c0/0x330)
> [<803dc674>] (search_nested_keyrings) from [<803dcb6c>]
> (keyring_search_aux+0xd8/0x130)
> [<803dcb6c>] (keyring_search_aux) from [<803df400>]
> (search_my_process_keyrings+0xd4/0x194)
> [<803df400>] (search_my_process_keyrings) from [<803df4e4>]
> (search_process_keyrings+0x24/0x10c)
> [<803df4e4>] (search_process_keyrings) from [<803dfa78>]
> (lookup_user_key+0x358/0x500)
> [<803dfa78>] (lookup_user_key) from [<803de2cc>] (keyctl_setperm_key+0x24/0xa4)
> [<803de2cc>] (keyctl_setperm_key) from [<80107dfc>]
> (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=invocation_id
>
> CPU: 0 PID: 353 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803df864>]
> (lookup_user_key+0x144/0x500)
> [<803df864>] (lookup_user_key) from [<803de2cc>] (keyctl_setperm_key+0x24/0xa4)
> [<803de2cc>] (keyctl_setperm_key) from [<80107dfc>]
> (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=invocation_id
>
> ... And then when accessing a file we see
>
>
> CPU: 0 PID: 475 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803dcb14>]
> (keyring_search_aux+0x80/0x130)
> [<803dcb14>] (keyring_search_aux) from [<803dcc58>] (keyring_search+0x94/0xcc)
> [<803dcc58>] (keyring_search) from [<803f17b4>] (asymmetric_verify+0x90/0x1ec)
> [<803f17b4>] (asymmetric_verify) from [<803f7020>] (evm_verify_hmac+0x204/0x258)
> [<803f7020>] (evm_verify_hmac) from [<803f6894>]
> (ima_appraise_measurement+0x12c/0x3a4)
> [<803f6894>] (ima_appraise_measurement) from [<803f2aa8>]
> (process_measurement+0x464/0x4d8)
> [<803f2aa8>] (process_measurement) from [<803f2b44>] (ima_file_check+0x28/0x30)
> [<803f2b44>] (ima_file_check) from [<8025873c>] (path_openat+0x67c/0x1414)
> [<8025873c>] (path_openat) from [<8025a9b0>] (do_filp_open+0x70/0xdc)
> [<8025a9b0>] (do_filp_open) from [<8024f9c0>] (do_open_execat+0x74/0x188)
> [<8024f9c0>] (do_open_execat) from [<8025125c>] (do_execveat_common+0x1f4/0x84c)
> [<8025125c>] (do_execveat_common) from [<80251ad8>] (SyS_execve+0x30/0x38)
> [<80251ad8>] (SyS_execve) from [<80107dfc>] (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=.ima_blacklist
>
> But that seems to be ok. Here's an example of where ubihealthd fails
> to get a key and it looks like it is failing EVM when trying to open a
> file.
>
> CPU: 0 PID: 530 Comm: (ihealthd) Tainted: G O
> 4.9.11-1.0.0+gc27010d #25
> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> [<8010ea60>] (unwind_backtrace) from [<8010c4d8>] (show_stack+0x10/0x14)
> [<8010c4d8>] (show_stack) from [<803e8784>] (smack_key_permission+0x2c/0xe0)
> [<803e8784>] (smack_key_permission) from [<803e7dd0>]
> (security_key_permission+0x3c/0x5c)
> [<803e7dd0>] (security_key_permission) from [<803dcb14>]
> (keyring_search_aux+0x80/0x130)
> [<803dcb14>] (keyring_search_aux) from [<803dcc58>] (keyring_search+0x94/0xcc)
> [<803dcc58>] (keyring_search) from [<803f1808>] (asymmetric_verify+0xe4/0x1ec)
> [<803f1808>] (asymmetric_verify) from [<803f7020>] (evm_verify_hmac+0x204/0x258)
> [<803f7020>] (evm_verify_hmac) from [<803f6894>]
> (ima_appraise_measurement+0x12c/0x3a4)
> [<803f6894>] (ima_appraise_measurement) from [<803f2aa8>]
> (process_measurement+0x464/0x4d8)
> [<803f2aa8>] (process_measurement) from [<803f2b44>] (ima_file_check+0x28/0x30)
> [<803f2b44>] (ima_file_check) from [<8025873c>] (path_openat+0x67c/0x1414)
> [<8025873c>] (path_openat) from [<8025a9b0>] (do_filp_open+0x70/0xdc)
> [<8025a9b0>] (do_filp_open) from [<8024f9c0>] (do_open_execat+0x74/0x188)
> [<8024f9c0>] (do_open_execat) from [<8025125c>] (do_execveat_common+0x1f4/0x84c)
> [<8025125c>] (do_execveat_common) from [<80251ad8>] (SyS_execve+0x30/0x38)
> [<80251ad8>] (SyS_execve) from [<80107dfc>] (__sys_trace_return+0x0/0x10)
> keyp->index_key->description=.evm
> integrity: Request for unknown key 'id:a35fd9c6' err -13
>
> So I'm guessing using SMACK and IMA together is going to require a bit of work.
> How about if I set the label of the .evm and probably .ima keyrings to
> '*'? I shall try and report back.
So labelling the .evm .ima and .ima_blacklist keyrings with '*' in
smack_key_alloc fixed things. We also add a certificate to the .ima
and .evm keyrings for verifying signatures that also needs labelling
with '*'. I was hoping to put some code in to automatically label all
keys linked to these keyrings with '*'. 'The problem was that in
smack_key_alloc it hadn't been linked with any keyring and I don't
think any of the other key LSM hooks help, so we just check the keys
description for a certain string.
