sssd also needs `attach_disconnected` in its apparmor profile

[Nish Aravamudan]

Similar to LP: #1727202 and other packages (libvirtd, e.g.) it seems like sssd also needs an `attach_disconnected` profile option. Symptomatically, what we see is that when we boot a node that uses sssd for authentication with the `overlayroot=tmpfs` option, sssd fails to start.

If I modify sssd to include the afore-mentioned option and then restart sssd, ssh and authentication works fine. The error appears to be from the underlying ldb code.

[Nish Aravamudan (nacc)]

1) # aa-enforce usr.sbin.sssd (default)

journal contains:

Jan 27 17:46:27 s2r5node66 sssd[3382]: ldb: unable to open modules directory '/usr/lib/x86_64-linux-gnu/ldb/modules/ldb'
Jan 27 17:46:25 s2r5node66 systemd[1]: Starting System Security Services Daemon...
Jan 27 17:46:25 s2r5node66 systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 27 17:46:25 s2r5node66 systemd[1]: sssd.service: Failed with result 'exit-code'.
Jan 27 17:46:25 s2r5node66 systemd[1]: Failed to start System Security Services Daemon.

2) # aa-complain usr.sbin.sssd; systemctl restart sssd

Jan 27 17:50:07 s2r5node66 audit[10294]: AVC apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/sssd" name="usr/lib/x86_64-linux-gnu/ldb/modules/ldb" pid=10294 comm="sssd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

3) modify /etc/apparmor/usr.sbin.sssd

/usr/sbin/sssd flags=(complain,attach_disconnected) {

# aa-enforce usr.sbin.sssd

/usr/sbin/sssd flags=(attach_disconnected) {

# systemctl restart sssd

● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-01-27 17:53:06 UTC; 7s ago

and ssh works again.

[Sergio Durigan Junior (sergiodj)]

Thanks for the bug report.

Initially I wasn't able to reproduce it with a pristine installation of Ubuntu Bionic + sssd, then aa-enforcing sssd, and then enabling overlayroot=tmpfs. sssd was able to start successfully.

Then, we had a chat on IRC where Andreas let me know that sssd's autopkgtest does have scripts that setup a simple LDAP + sssd auth scheme, so I used that to perform the tests. I download sssd's source, manually ran the debian/tests/ldap-user-group-ldap-auth, which create a "testuser1" in the LDAP database. I also tested that this user is able to login and ssh into the VM. Then, aa-enforced sssd and enabled overlayroot=tmpfs:

# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=491068k,nr_inodes=122767,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=100488k,mode=755)
/dev/sda2 on /media/root-ro type ext4 (ro,relatime,data=ordered)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime)
overlayroot on / type overlay (rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
...

To no avail: I'm still able to start sssd and perform logins/ssh into the machine.

I'll continue investigating tomorrow, but it's important to obtain a reproducer for this one because we will need to SRU it into Bionic.

[Andreas Hasenack (ahasenack)]

Something to think about: how common is this use case (of overlayfs), and if there are other scenarios where the lack of `attach_disconnected` is troublesome?

We should consider if enabling this option introduces unnecessary security risks for the supposedly wider audience who is NOT using overlayfs.

[Nish Aravamudan (nacc)]

I'm wondering now if *perhaps* kernel or kexec is involved. I don't reboot directly to the overlay kernel, I use:

`kexec --initrd=/boot/initrd.img-$(uname -r) --command-line="$(cat /proc/cmdline`) overlayroot=tmpfs" /boot/vmlinuz-$(uname -r) -l`

And we are on a custom 5.4 kernel (it's the nature of our HVs that we don't run the Ubuntu kernel). Can you try with kexec instead of overlayroot.conf config?

And can you tell me what kernel is in your VM?

The last part is this is baremetal, but I don't think that should matter.