Hi Stephen,
Here are the outputs of the commands you asked for...
Before restarting sshd, while the problem is exhibited:
------------------------------------------------------------------------------
root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login
0 0
root@hapWibbSc2:/> grep ssh /etc/selinux/strict/contexts/default_contexts
system_r:sshd_t:s0 user_r:user_t:s0 staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
root@hapWibbSc2:/> ps -eZ | grep sshd
system_u:system_r:kernel_t:s0 1095 ? 00:00:00 sshd
And after restarting sshd from the console, where I am root:sysadm_r:sysadm_t:s0
--------------------------------------------------------------------------------------------------------------------------
root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login
0 0
root@hapWibbSc2:/> grep ssh /etc/selinux/strict/contexts/default_contexts
system_r:sshd_t:s0 user_r:user_t:s0 staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
root@hapWibbSc2:/> ps -eZ | grep sshd
root:system_r:sshd_t:s0 4819 ? 00:00:00 sshd
Just in case, under the /etc/selinux/strict/contexts/users/ directory, I only have one file called "root", and that contains:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
system_r:local_login_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 user_r:user_t:s0
system_r:crond_t:s0 sysadm_r:sysadm_crond_t:s0 staff_r:staff_crond_t:s0 user_r:user_crond_t:s0
staff_r:staff_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 user_r:user_t:s0
sysadm_r:sysadm_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 user_r:user_t:s0
user_r:user_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 user_r:user_t:s0
#
# Uncomment if you want to automatically login as sysadm_r
#
#system_r:sshd_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 user_r:user_t:s0
*** So given this info, we can see that in the problematic case, context of sshd is system_u:system_r:kernel_t:s0, but restarting sshd on the console, we get root:system_r:sshd_t:s0. And after this, everything works nicely...
So how can I programmatically (e.g. through a script) get sshd to start in the right context, or force sshd to change context to sshd_t ?
Thanks again for all your help as always :-)
- Reza.
-----Original Message-----
From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx]
Sent: Tuesday, February 12, 2008 12:58 PM
To: Hasan Rezaul-CHR010
Cc: Dave Quigley
Subject: RE: Accurately setting Security Context of a user when ssh-ing in
On Tue, 2008-02-12 at 12:53 -0500, Hasan Rezaul-CHR010 wrote:
> Here is the full story... Apologize for dragging this on...
any reason you didn't cc the list?
> I have SELinux running on a Linux Card.
> The Card is partitioned into 2 halves! One half (the active side)
> running software and a set of SELinux policies already.
> And another half, the inactive side, which is usually empty.
>
> I have a software upgrade procedure, where software is first downloaded
> and populated on the 2nd half (/inactive/ side), and then the card is
> rebooted to come up on the newly populated side. This way software
> upgrade is done with minimal downtime.
>
> As part of the software_upgrade procedure, I place new software, and a
> collection of SELinux policies on the inactive side.
> So basically I populate everything under the
> /inactive/etc/selinux/***
> as well as create and mount the selinuxfs at /inactive/selinux
>
> After the /inactive side is appropriately populated with new software
> and new policies, 'sidesel' is modified,
> and the Linux card is REBOOTED !
>
> The card then starts coming up on the new side, kernel recognizes new
> SELinux policies, and loads the new policy !
> By the way, I removed the /.autorelabel file, because I didn't want
> kernel to reboot the Card again !?!
>
> So I have an init script that runs during bootup, and the script does
> "restorecon -rF /"
>
> So after this point, when the Card is fully up, the card is running with
> new SELinux policies, and filesystem labeled appropriately!
>
> My login mappings at this time are defined as follows:
>
> root@hapWibbSc2:/etc> semanage login -l
>
> Login Name SELinux User MLS/MCS Range
>
>
> __default__ user_u s0
>
> Admin staff_u s0
>
> root root s0-s0:c0.c1023
>
> system_u system_u s0-s0:c0.c1023
>
>
> At this time:
>
> 1. If I login as root on the console, I expect, and I do get,
> root:sysadm_r:sysadm_t:s0
> 2. If I ssh in as Admin, I expect to get staff_u:staff_r:staff_t, but
> instead, I get staff_u:sysadm_r:sysadm_t !!
What do the following commands show?
# getsebool ssh_sysadm_login
# grep ssh /etc/selinux/$SELINUXTYPE/contexts/default_contexts
> 3. Also If I ssh in as a regular user, like Reza, I should get
> user_u:user_r:user_t, but I get system_u:system_r:system_t !!
Strange.
> As you suggested in your previous mail(s), perhaps the sshd process
> wasn't started under the right contexts ???
Yep, what does ps -eZ | grep sshd show?
> So, here is the interesting part:
>
> - While I am logged in as root on the console, and my context is
> root:sysadm_r:sysadm_t, if I type /sbin/service sshd restart,
> and then try to ssh in as Admin or Reza, after that, I do get the
> correct contexts, and everything is golden :-)
And what does ps -eZ | grep sshd show now?
> - OR another thing that works is: while I am logged in as root on the
> console (as sysadm), I execute a script that has 'service sshd restart'
> in it. This also fixes the problem
>
> BUT, I need to find an automatic/programmatic way to do this, because
> the software_upgrade procedure must be automatic ! It cant involve
> someone manually logging in to do something on the console.
>
> - So in my init script that runs during bootup, where I relabel the
> filesystem, after relabelling, I put /sbin/service sshd restart
> but after that script ran, I still have this problem :-( That's
> probably because the init script is being run as "system" during bootup,
> whereas when I manually typed on the console, I am "sysadm".
>
> - I tried many different things, e.g. ssh-ing in as Admin or Reza, then
> su - root, and then restarting sshd, but nothing works !!!
> The only thing that resolves this problem, is executing "service sshd
> restart" at the console, where my context is root:sysadm_r:sysadm_t.
>
> - Of course, the other thing that works, is rebooting the Card a second
> time, which I cant afford, due to availability requirements.
>
>
> Do you have any suggestions of how I can restart the sshd process
> programmatically (e.g. through my init script), to achieve the same
> results as running the 'service sshd restart' manually on the console ?
> Is there a way my init script could temporarily assume sysadm, or a way
> that my init script can be run as sysadm during bootup ?
Well, you can always force it into a certain context via runcon (if
permitted by your policy). But I'd rather fix the real problem, and
that requires knowing what context sshd is running in initially and then
what context is it running in after the restart from the console.
> Thanks again for all your help...
--
Stephen Smalley
National Security Agency
