[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] AVCs on fedora atomic host 91f0a3478e preventing ssh login
- From: Tobias Florek <atomic ibotty net>
- To: Daniel J Walsh <dwalsh redhat com>, atomic-devel projectatomic io
- Subject: Re: [atomic-devel] AVCs on fedora atomic host 91f0a3478e preventing ssh login
- Date: Mon, 14 Sep 2015 16:52:49 +0200
Hi,
> >> 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?
# ls -lZ /var/lib/machines/ipsec-libreswan/etc/resolv.conf
-rwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 147 Sep 14 09:15 /var/lib/machines/ipsec-libreswan/etc/resolv.conf
> >> 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.
> >
> Wierd, not sure how atomic would get mislabeled? ps -eZ | grep sshd
# ps -eZ | grep sshd
system_u:system_r:kernel_t:s0 1811 ? 00:00:00 sshd
unconfined_u:unconfined_r:unconfined_t:s0 1818 ? 00:00:00 sshd
system_u:system_r:kernel_t:s0 1970 ? 00:00:00 sshd
interestingly:
# ls -lZ /usr/sbin/sshd
-rwxr-xr-x. 3 root root system_u:object_r:default_t:s0 870280 Jan 1 1970 /usr/sbin/sshd
which is different from the other atomic hosts, which have
system_u:object_r:sshd_exec_t:s0 as expected.
> 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?
Native on atomic.
Should I let that machine stay around for debugging further, or
should I just install a new machine?
Thanks in advance,
Tobias Florek
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]