On Mon, Jul 22, 2019 at 10:35 PM Martin Townsend <mtownsend1973(a)gmail.com&gt; wrote:

> On Mon, Jul 22, 2019 at 10:23 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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(a)schaufler-ca.com&gt; 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? > 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"

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?