[systemd-devel] nspawn remounts /selinux readonly, thus breaking logins

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Fri Jul 8 05:18:00 PDT 2011


On 07/08/2011 01:59 PM, Daniel J Walsh wrote:
> On 07/08/2011 07:45 AM, Lennart Poettering wrote:
>> On Fri, 08.07.11 10:41, Zbigniew Jdrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
>>>
>>> On 07/07/2011 11:17 PM, Lennart Poettering wrote:
>>>> On Thu, 07.07.11 16:52, Daniel J Walsh (dwalsh at redhat.com) wrote:
>>>>
>>>>>>> This has a nasty consequence of breaking logins:
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14261]: Accepted publickey for zbyszek from 192.168.122.1 port 51205 ssh2
>>>>>>> Jul  7 20:17:05 fedora-15 sshd[14262]: fatal: mm_request_receive: read: Connection reset by peer
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): conversation failed
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): No response to query: Would you like to enter a security context? [N] 
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): Unable to get valid context for zbyszek
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14261]: pam_unix(sshd:session): session opened for user zbyszek by (uid=0)
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14261]: error: PAM: pam_open_session(): Authentication failure
>>>>>>> Jul  7 22:17:05 fedora-15 sshd[14264]: Received disconnect from 192.168.122.1: 11: disconnected by user
>>>>>>>
>>>>>>> In case of a login on a tty, the question about a security context
>>>>>>> is displayed on the screen. In case of ssh login, if just fails
>>>>>>> without any message displayed on the remote side.
>>>>>>
>>>>>> Newer versions of libselinux detect if /selinux is read-only and consider
>>>>>> selinux disabled if it is.
>>> But why is it disabled _outside_ of the container? This would mean that running
>>> nspawn disables selinux.
> 
>> Hmm?
> 
>> No, it's read-only only inside the container. We do that to make sure
>> the container cannot modify the selinux policy, since policies cannot be
>> virtualized really.

Nope, it becomes read-only outside. Some bug?
Repeating the commands from the original mail:

[zbyszek at fedora-15 ~]$ mount|grep selinux
selinuxfs on /selinux type selinuxfs (rw,relatime)      <----------------- RW here
[zbyszek at fedora-15 ~]$ sudo systemd-nspawn -D debian-tree/ /bin/true
Spawning namespace container on /home/zbyszek/debian-tree (console is /dev/pts/2).
[zbyszek at fedora-15 ~]$ mount|grep selinux
selinuxfs on /selinux type selinuxfs (ro,relatime)      <----------------- RO now

> I have no idea what nspawn does, but if you are turning the /selinux to
> readonly to prevent a root process from mucking with SELinux you are not
> going to be successful.  Since you can mount selinufs somewhere else and
> muck around with it. 
As I understand, absolute security is not on of the goals of nspawn. It is
only intended to prevent accidental breakage.

> If you want to run all of the processes within the
> nspawn environment under a single label, Like we do with Mock, then
> changing /selinux to read/only with the libselinux in Rawhide will give
> you want you want.  IE All processes within the container think SELinux
> is disabled, while SELinux is actually running all of the processes
> under confinement.

Zbyszek


More information about the systemd-devel mailing list