On 09/14/2015 09:11 AM, Tobias Florek wrote:
> 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
I have no idea. What does ls -lZ /etc/resolv.conf show?
>>> 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
>
Wierd, not sure how atomic would get mislabeled? ps -eZ | grep sshd
Should be running as sshd_t not kernel_t? Are you doing this into the
systemd-nspawn container, or
is the sshd_t native on atomic?
