On Wed, 2009-01-07 at 15:19 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michal Jaegermann wrote: > > On Sun, Jan 04, 2009 at 02:29:44PM -0500, Daniel J Walsh wrote: > >> If you execute service sshd restart from the unconfined_t user does it > >> still start as system_crond_t? > > > > # /etc/init.d/sshd restart > > Stopping sshd: [ OK ] > > Starting sshd: [ OK ] > > # ps -eZ | grep ssh > > system_u:system_r:system_crond_t:s0 23026 ? 00:00:00 sshd > > system_u:system_r:system_crond_t:s0 23074 ? 00:00:00 sshd > > > > and the same after logging out and loging back in. > > > > /usr/sbin/sshd has system_u:object_r:sshd_exec_t:s0 for its label. > > > >> I actually just upgraded my Fathers machine from F8 to F10 and had a > >> problem with the root account not being setup to login correctly. But I > >> saw no problems with sshd? > > > > Other problems may show up yet. I do not know. > > > > I do not think that this happens consistently across installations > > and so far I do not see any rhyme or reason. On another box you may > > not even notice that something is amiss. It is not hard to imagine > > that you _think_ that you have a selinux protection after an upgrade > > while in reality everything is totally out-of-whack. > > > > The other machine which went through F8->F10 upgrade, and which I > > was using for comparisons, does not give me any grief but I am not > > sure if it really looks like it should. > > > > Michal > > > Adding Steven Smalley for a fresh set of eyes. An earlier posting showed that his shell was running in system_crond_t, so it isn't surprising then that restarting sshd from that shell would leave it in system_crond_t (domain transitions are defined on the caller domain and the executable type, and there isn't any such transition defined from system cron jobs on executing sshd). Then any subsequent login attempt via ssh would be similarly botched, because sshd is running in system_crond_t, and thus the starting domain isn't what the system expects and when we ask the system what user contexts are reachable from that starting domain, it gets rather puzzled. Reboot the system, then login and look at pstree -Z output. As to the original cause, I assume that this is due to: 1) The rather major changes that took place in the policy across these versions (in particular the merging of targeted and strict policies and the change to using unconfined_u and unconfined_r for unconfined processes), and 2) The (mis)use of semanage by the selinux-policy package to manage the seuser definitions rather than shipping one in the base policy package as originally intended and only using semanage for local customizations, thereby breaking the ability to cleanly upgrade (or at least making it rather fragile). -- Stephen Smalley National Security Agency -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
