On Wed, 2008-02-13 at 15:23 -0500, Stephen Smalley wrote: > On Wed, 2008-02-13 at 15:02 -0500, Hasan Rezaul-CHR010 wrote: > > Hi Stephen, > > > > As part of my software_upgrade procedure, after populating the new > > policies and selinuxfs on the /inactive side, I did "touch > > /inactive/.autorelabel" > > > > Then reboot my Linux Card. So now when the Card was booting up from the > > new side... > > > > kernel detected new policies, > > loaded new policies, > > kernel also detected the .autorelabel file > > kernel doesn't do that - it is handled by /etc/rc.sysinit (at least in > Fedora). > > > So it invoked automatic "Re-Label" of the filesystem > > Kernel then FORCED another Automatic REBOOT > > And then the Card booted up all the way. > > > > Now when I do "ps -eZ | grep sshd", I get > > > > root@hapWibbSc2:/root> ps -eZ | grep sshd > > system_u:system_r:init_t:s0 3971 ? 00:00:00 sshd > > Ok, normally, /sbin/init runs in init_t, then it transitions to initrc_t > upon executing the /etc/rc.d/ and /etc/init.d scripts, and then initrc_t > transitions to sshd_t upon executing /usr/sbin/sshd. > > So now your problem is that you aren't transitioning to initrc_t. > What's the label on /etc/rc.d and /etc/init.d, i.e. ls > -Z /etc/rc.d /etc/init.d? > > If init directly invokes sshd in your setup, then you need a type > transition rule added for it since that isn't the usual case. > > > So this way, we've made sure that the filesystem was labeled correctly, > > before the init processes were started! > > You mentioned that ideally, this is the sequence we want, correct ??? > > Yes. You could also label the /inactive tree _before_ booting from it > if the file types haven't changed from the old policy, ala: > # setfiles -r /inactive /inactive/etc/selinux/$SELINUXTYPE/contexts/file_contexts /inactive > > The -r option tells setfiles to use an alternate root path, for labeling a separate > tree like this. Just to follow up for the list - Hasan tried the above approach of using setfiles -r to label the /inactive tree before rebooting, and that solved his problem. Also, just to note for others: the above presumes that the new file_contexts configuration doesn't include any new file types not defined by the running policy. To support a change where new file types are introduced, you'd have to first load the new policy before running setfiles, ala: # chroot /inactive load_policy # setfiles -r /inactive /inactive/etc/selinux/$SELINUXTYPE/contexts/file_contexts /inactive And that will only work if the policies are reasonably compatible with one another. For a major change in policy (e.g. targeted -> strict, non-mls -> mls), you'd likely need to go for the full reboot + relabel sequence instead. > > > *BUT*, how even after re-labeling the filesystem, and starting sshd, the > > context became = system_u:system_r:init_t ?? > > Apparently it isn't transitioning out of init_t into initrc_t before > reaching sshd. > > > Now when I ssh in as "Admin", or "Reza" I still get the wrong context ! > > :-( > > > > > > Things actually seem to work properly when the sshd process is running > > in context = root:system_r:sshd_t:s0 > > > > In my normal setup, I DON'T create an /.autorelabel file, and I do the > > re-labeling manually via a script using restorecon. The problem with > > that approach is that, init processes like 'sshd' already get started in > > the wrong context BEFORE my script gets a chance to run. > > > > But if I restart sshd from the console, my ssh headaches get resolved. > > So how can I restart ssh in the correct context (system_r:sshd_t) via > > a script? You mentioned something about the "runcon" command... Can I > > use 'runcon' in my script to restart sshd and force sshd to run it in > > the correct context ?? > > > > You're right that other init processes may be running in the wrong > > context/domain as well, but they're not bothering me as much. But I need > > to at least get around this ssh problem... Any suggestions ?... Thanks, > > You can use runcon (if permitted by policy), but I think we can fix this > w/o doing that. > -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
