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