Re: [atomic-devel] AVCs on fedora atomic host 91f0a3478e preventing ssh login

[Tobias Florek <atomic ibotty net>]

Hi,

thanks for looking into it.


> >     type=AVC msg=audit(1442045142.791:158569): avc:  denied  { read } for pid=3358 comm="nslookup" name="resolv.conf" dev="dm-1" ino=95751 scontext=system_u:system_r:svirt_lxc_net_t:s0:c411,c700 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c722,c900 tclass=file permissive=1
> >     type=AVC msg=audit(1442045142.791:158570): avc:  denied  { ioctl } for pid=3358 comm="nslookup" path="/etc/resolv.conf" dev="dm-1" ino=95751 scontext=system_u:system_r:svirt_lxc_net_t:s0:c411,c700 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c722,c900 tclass=file permissive=1
> >     [many more of these with different pids]
> This looks like you have a /etc/resolv.conf from one machine leaking
> into another?  Are you volume mounting in /etc/resolv.conf into containers?

I am not doing so directly. Might that be systemd-nspawn? I have
a container running that is invoked with

    /bin/systemd-nspawn --quiet --capability all --tmpfs /var/run/pluto \
        --bind /proc/sys/net --bind-ro /lib/modules --bind /etc/ipsec \
        --bind /etc/ipsec.d --machine=ipsec-libreswan \
        /bin/entrypoint.sh start

> >     type=AVC msg=audit(1442048674.527:162109): avc:  denied  { lock } for  pid=20655 comm="etcd" path="/var/ etcd/data/member/wal/0000000000000011-0000000000029822.wal" dev="dm-1" ino=109294 scontext=system_u:syst em_r:svirt_lxc_net_t:s0:c369,c609 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1
> >
> >     type=AVC msg=audit(1442213538.406:164): avc:  denied { dyntransition } for  pid=1808 comm="sshd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:sshd_net_t:s0 tclass=process permissive=0 type=AVC msg=audit(1442213539.950:183): avc:  denied { dyntransition } for  pid=1814 comm="sshd" sconte xt=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0
> Looks like sshd is running as kernel_t, which indicates to me the system
> needs to be relabeled.
>
> touch /.autorelabel; reboot
>
> Should fix the labels.

unfortunately it's an atomic host and I can't touch that file. I assume,
even the autorelabeler won't be able to change the labels. A
    restorecon -nR /
does not tell me anything that is wrong.

Cheers,
 Tobias Florek