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