All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hasan Rezaul-CHR010" <CHR010@motorola.com>
To: "Stephen Smalley" <sds@epoch.ncsc.mil>,
	"Christopher J. PeBenito" <cpebenito@tresys.com>
Cc: "SELinux" <selinux@tycho.nsa.gov>
Subject: Console Login and SSH Login  Security Contexts...
Date: Sun, 31 Oct 2010 18:36:37 -0400	[thread overview]
Message-ID: <D06FE0A2807BC145B0D38744789D4F5D09C2E5DC@de01exm68.ds.mot.com> (raw)
In-Reply-To: <20100314053521.GA12410@us.ibm.com>

Hi All,

I know there was a huge email thread recently regarding obtaining
correct security context after SSH-login, but I didn't really get the
answer I need from that thread. So hoping someone can help me...

I work on a 2.6.27 Linux system, where there are two partitions. A "/"
partition where all the active software runs, and an "/inactive"
partition where we download new software. 

During a software upgrade procedure, we populate the "/inactive"
partition with new software. 
We also have selinux policies loaded up on the /inactive side (so
/inactive/etc/selinux/strict/*), 
and I use the "setfiles" command to label the entire /inactive partition
correctly. 
and then we do a reboot and flip the partitions, so that the previous
/inactive side now becomes the "/" side, and the new software runs.


My SELinux user and login configuration is as below:


root@hapWibbSc2:~# semanage user -l  
                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range
SELinux Roles

root            sysadm     s0         s0-s15:c0.c255
staff_r sysadm_r
staff_u         staff      s0         s0-s15:c0.c255
staff_r sysadm_r
sysadm_u        sysadm     s0         s0-s15:c0.c255
sysadm_r
system_u        user       s0         s0-s15:c0.c255
system_r
unconfined_u    unconfined s0         s0-s15:c0.c255
unconfined_r
user_u          user       s0         s0
user_r



root@hapWibbSc2:~# semanage login -l                           
Login Name      SELinux User		  MLS/MCS Range

root            root                  s0-s15:c0.c255                 
admin           staff_u               s0                          
system_u        system_u              s0-s15:c0.c255    
__default__     user_u                s0             
                   

What I would like to see is:

when Linux User = 'root' logs into the console or through SSH, I would
like to see context = root:sysadm_r:sysadm_t
when Linux User = 'admin' logs into the console or through SSH, I would
like to see context = staff_u:staff_r:staff_t
when Linux User = 'Test' logs into the console or through SSH, I would
like to see context = user_u:user_r:user_t


After the software_upgrade (when the filesystem has already been labeled
correctly, and after the reboot, I would expect the "login" process and
the "sshd" process to run under the correct context
(system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).  But
I don't  :-(  I see them both running as  system_u:system_r:kernel_t
!!!  This tells me that the domain transitions during the init sequence
perhaps didn't go smoothly ?

And as a result, when each of the users login to the console or through
SSH, they get a wrong security context like staff_u:staff_r:insmod_t
!!!

Note: If the Linux machine is reboot ONE MORE TIME, then the 'login' and
'sshd' processes run in the correct context, and from that point on,
each user does get the security context as desired !  But in my
production system, I cant afford to have a second reboot due to timing
contraints  :-(  And I honestly don't understand why another reboot
would be necessary, considering the filesystem was already labeled and
the node was already reboot once... Why the need for this extra reboot
to set things right ? Besides, this additional reboot is NOT relabeling
anything, which means the labelling during the previous bootup was
fine...


QUESTIONS
==========

1. Any pointers as to what may be happenning ? Why processes are running
in wrong context after the first reboot ?
2. What does an additional (2nd) reboot do, that gets the processes
running in the correct context ?
3. Is there something I can do (other than 2nd reboot)  perhaps through
a script that would allow the 'login' and 'sshd' processes to restart in
the correct context ? Perhaps the "run_init" command ??
4. Anyway I can force the domain transitions to occur correctly ?
5. What is a typical sequence of domain transitions anyway during a
typical Linux bootup ?


The strange thing is, the software upgrade procedure (as described
above) and login context setting used to work just fine in conjunction
with my selinux policies, and users would obtain the correct security
contexts after loggin in... And this used to work just fine in the
previous software release after just the first reboot. But in our new
software release, this behaviour seems to have changed  :-(  But there
was no real change to selinux policies, so trying to understand what
happened??  Any pointers would be greatly appreciated. Thank You  :-)


R.H.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2010-11-01 11:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-12 20:55 [PATCH] Define CAP_SYSLOG Serge E. Hallyn
2010-03-12 20:55 ` Serge E. Hallyn
2010-03-12 20:58 ` [refpolicy] [PATCH refpolicy] add capability2:syslog perm Serge E. Hallyn
2010-03-14  5:18 ` [PATCH] Define CAP_SYSLOG Michael Kerrisk
2010-03-14  5:35   ` Serge E. Hallyn
2010-03-14  5:35     ` Serge E. Hallyn
2010-03-15  1:16     ` Matthew Helsley
2010-03-15  4:24       ` Serge E. Hallyn
2010-03-15  4:24         ` Serge E. Hallyn
2010-10-31 22:36     ` Hasan Rezaul-CHR010 [this message]
2010-11-01 15:59       ` Console Login and SSH Login Security Contexts Christopher J. PeBenito
2010-11-01 21:11         ` Hasan Rezaul-CHR010
2010-11-02  7:48           ` HarryCiao
2010-11-02 13:36           ` Christopher J. PeBenito
2010-11-02 18:12             ` Hasan Rezaul-CHR010
2010-11-01  5:27     ` Format of file_contexts file Hasan Rezaul-CHR010
2010-11-01 16:02       ` Christopher J. PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D06FE0A2807BC145B0D38744789D4F5D09C2E5DC@de01exm68.ds.mot.com \
    --to=chr010@motorola.com \
    --cc=cpebenito@tresys.com \
    --cc=sds@epoch.ncsc.mil \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.