sssd also needs `attach_disconnected` in its apparmor profile

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.

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.

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.

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.