Hi all,
I have a problem trying to run sshd via xinetd on a CentOS 5.4 system (I want to slap a tcpwrappers-style wrapper before sshd, so I need it that way).
In permissive mode I can log in/out with the following failures reported by audit2allow:
allow amanda_t consoletype_exec_t:file { execute execute_no_trans }; allow amanda_t devpts_t:chr_file { write ioctl }; allow amanda_t hostname_exec_t:file { execute execute_no_trans }; allow amanda_t shell_exec_t:file entrypoint;
I don't even have amanda installed, so the context is clearly bogus.
After a chat on #fedora-selinux it seems that sshd cannot find its default context, so falls back to the first available one, which happens to be something:something:amanda_t (the list is read from /selinux/user). This operation is performed by sshd itself (as verified by strace).
I don't need Fort Knox type security but I'd like to use SELinux to tighten down other parts of the system, so I'd really like to use the enforcing mode.
Any hints? A good TFM to R will hopefully do.
Best regards, Grzegorz Nosek
On 12/31/2009 05:06 AM, Grzegorz Nosek wrote:
Hi all,
I have a problem trying to run sshd via xinetd on a CentOS 5.4 system (I want to slap a tcpwrappers-style wrapper before sshd, so I need it that way).
In permissive mode I can log in/out with the following failures reported by audit2allow:
allow amanda_t consoletype_exec_t:file { execute execute_no_trans }; allow amanda_t devpts_t:chr_file { write ioctl }; allow amanda_t hostname_exec_t:file { execute execute_no_trans }; allow amanda_t shell_exec_t:file entrypoint;
I don't even have amanda installed, so the context is clearly bogus.
After a chat on #fedora-selinux it seems that sshd cannot find its default context, so falls back to the first available one, which happens to be something:something:amanda_t (the list is read from /selinux/user). This operation is performed by sshd itself (as verified by strace).
I don't need Fort Knox type security but I'd like to use SELinux to tighten down other parts of the system, so I'd really like to use the enforcing mode.
Any hints? A good TFM to R will hopefully do.
Best regards, Grzegorz Nosek
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
This looks like you have a very screwed up system.
What domain is sshd running with?
ps -eZ | grep sshd
You could try a relabel
touch /.autorelabel; reboot
Which should get all the processes running in the correct domain.
On Thu, 2009-12-31 at 11:06 +0100, Grzegorz Nosek wrote:
Hi all,
I have a problem trying to run sshd via xinetd on a CentOS 5.4 system (I want to slap a tcpwrappers-style wrapper before sshd, so I need it that way).
In permissive mode I can log in/out with the following failures reported by audit2allow:
allow amanda_t consoletype_exec_t:file { execute execute_no_trans }; allow amanda_t devpts_t:chr_file { write ioctl }; allow amanda_t hostname_exec_t:file { execute execute_no_trans }; allow amanda_t shell_exec_t:file entrypoint;
I don't even have amanda installed, so the context is clearly bogus.
After a chat on #fedora-selinux it seems that sshd cannot find its default context, so falls back to the first available one, which happens to be something:something:amanda_t (the list is read from /selinux/user). This operation is performed by sshd itself (as verified by strace).
I don't need Fort Knox type security but I'd like to use SELinux to tighten down other parts of the system, so I'd really like to use the enforcing mode.
Any hints? A good TFM to R will hopefully do.
In what label/context are xinetd and sshd running (ps -eZ)? What are the file security contexts on their executables (ls -Z)?
On pon, sty 04, 2010 at 04:42:48 -0500, Stephen Smalley wrote:
I have a problem trying to run sshd via xinetd on a CentOS 5.4 system (I want to slap a tcpwrappers-style wrapper before sshd, so I need it that way).
In what label/context are xinetd and sshd running (ps -eZ)? What are the file security contexts on their executables (ls -Z)?
In the meantime I managed to get stuff running by adding a module like below.
xinetd is running with system_u:system_r:inetd_t:SystemLow-SystemHigh, sshd binary is labelled as system_u:object_r:sshd_exec_t, so I did not need any relabelling, I just needed the domain transition to switch sshd to unconfined_t. It stayed as inetd_t or went to inetd_child_t before; I can't remember right now and I'm not too willing to hack at it again due to kernel bugs (on a system broken in the right way the kernel panics in do_sys_open -> (..) -> chrdev_open -> ptmx_open -> init_dev; probably a missing IS_ERR somewhere).
I'd have expected the run_ssh_inetd tunable to do this but apparently, it does nothing at all in the targeted policy (as of CentOS 5.4).
So, for future reference, here's the module I needed:
--------------------- cut -------------------- module inetdssh 1.0.0;
require { type inetd_t; type unconfined_t; type sshd_exec_t; class process { transition }; }
#============= inetd_t ============== allow inetd_t unconfined_t:process transition; type_transition inetd_t sshd_exec_t : process unconfined_t;
#============= unconfined_t ============== allow unconfined_t self:process transition;
--------------------- cut --------------------
Best regards, Grzegorz Nosek
selinux@lists.fedoraproject.org