Supervisory Watchdog notification not working when using SmackProcessLabel

[mtownsend1973@xxxxxxxxx (Martin Townsend)]

Hi Casey,

Thanks you for you prompt response.
On Wed, Aug 1, 2018 at 5:32 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>
> On 8/1/2018 3:18 AM, Martin Townsend wrote:
> > Hi,
> >
> > I have a service running with a SmackProcessLabel that uses the
> > supervisory watchdog feature, ie calls sd_notify().  The Watchdog
> > keeps resetting the service and I get the following in the journal
> >
> > Jul 27 11:36:11 kernel: audit: type=1400 audit(1532691371.270:34):
> > lsm=SMACK fn=smack_unix_may_send action=denied subject="apphealthd"
> > object="_" requested=w pid=466 comm="apphealthd"
> > path="/run/systemd/notify"
> >
> > /run/systemd/notify is a socket so I'm guessing sd_notify kicks the
> > watchdog by writing to this socket.  The problem seems to be that the
> > socket is labelled with the floor label.
>
> What does "attr -S -g SMACK64 /run/systemd/notify" report?
> It should say that the attribute value is "*". If it doesn't,
> what kernel and systemd versions are you running? What is your
> base system? (Tizen, Fedora, ...)

It did report "*" for this socket file descriptor for the
security.SMACK64 attribute.
I'm running a 4.9 Kernel built using Yocto for the i.MX6UL so it's the
NXP 4.9 Kernel.  Systemd is 234 which is the version included in the
Rocko release of Yocto.

>
> UDS socket access controls are done based on the processes
> involved, not the file system object. Do you have any services
> running with the floor ("_") label?

Most services run with their own label but there are system services
running with the floor label.

>
>
> > After looking through the code that sets up the notify socket I
> > quickly patched in some code to set SMACK64IPIN and IPOUT (not sure if
> > this one is required).
> >
> > @@ -728,7 +729,12 @@ static int manager_setup_notify(Manager *m) {
> >
> >                  m->notify_fd = fd;
> >                  fd = -1;
> > -
> > +                r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "*");
> > +                if (r < 0)
> > +                        log_error_errno(r, "mac_smack_apply_ip_in_fd: %m");
> > +                r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPOUT, "@");
> > +                if (r < 0)
> > +                        log_error_errno(r, "mac_smack_apply_ip_out_fd: %m");
> >                  log_debug("Using notification socket %s", m->notify_socket);
> >          }
> >
> > And the audit message has gone.
>
> Your code above is the best way to ensure your service can
> talk to everyone. You have to be sure talking to everyone is
> really what you want to do.

This applies the SMACK64_IPIN and IPOUT on the notify socket
(/run/systemd/notify) so I'm hoping it means that any
application/service can write to the notify socket, as far as I can
tell this socket is used to kick the systemd supervisory watchdog for
a specific application.  If I used a specific label then I take it I
would have to use something like

r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "systemd_notify");

and have a rule like:

service_label systemd_notify rwx

for every service that runs with a SMACK process label and uses the
systemd supervisory watchdog.  I don't think there would be any harm
using '*' and '@' for /run/systemd/notify though to avoid this,
hopefully the systemd devs can confirm this?

>
> > Is there a better way of ensuring /run/systemd/notify can be accessed
> > by a service with a User defined SMACK label? or is this patch to
> > manager_setup_notify sufficient?
>
> You can always add access rules to allow communications.
> In this case it would be
>
>         apphealthd _ w
>         _ apphealthd w
>
> Generally you don't want to add rules for the floor ("_")
> label, but that's where you're seeing an issue. If you compile
> with SECURITY_SMACK_BRINGUP and use
>
>         apphealthd _ wb
>         _ apphealthd wb
>
> accesses permitted by these rules will be logged so that you
> can track down who you're talking to.

Yes, trying to avoid rules with floor in :)  Thanks for the tip on
SECURITY_SMACK_BRINGUP though, I'm sure it will come in useful in the
future.

>
> >
> > Many Thanks in Advance,
> > Martin.
> >
>