login process unable to execute /bin/sh

login process unable to execute /bin/sh

[Sam Gandhi]

I have labelled login and sh as shown below.

-rwxr-xr-x    1     25024 Jun 24 22:20 system_u:object_r:login_exec_t
 /bin/login
-rwxr-xr-x    1          15 Jun 24 18:40 system_u:object_r:bin_t
   /bin/sh

Following is output of ps -Z
      1 system_u:system_r:init_t         S    init
  583 system_u:system_r:local_login_t  S    login -- root

But when I login I see these messages :

Jan  1 10:00:23 192.168.137.1 kernel: type=1400 audit(23.040:40): avc:
 granted  { transition } for  pid=596 comm="getty" path="/bin/login"
dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
tcontext=system_u:system_r:local_login_t tclass=process
Jun 28 01:30:17 192.168.137.1 kernel: type=1400
audit(1309188617.348:46): avc:  denied  { transition } for  pid=833
comm="login" path="/bin/sh" dev=ubifs ino=93
scontext=system_u:system_r:local_login_t
tcontext=root:system_r:initrc_t tclass=process

I do see following statement in policy.conf (monolithic)

allow local_login_t initrc_t:process transition;

Also root is allowed to enter following roles:

user root roles { user_r sysadm_r staff_r system_r };

seusers file looks like this.

system_u:system_u
root:root
diags:diags_u
__default__:user_u

I am using pam for so here are the relevant debug messages from PAM,
in case something is going wrong there.

Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session): Open Session
Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session):
Username= root SELinux User = root Level= (null)
Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session): pam:
default-context=root:system_r:initrc_t
selected-context=root:system_r:initrc_t success 1
Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session):
Security Context root:system_r:initrc_t Assigned
Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session): set
root security context to root:system_r:initrc_t
Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session): Key
Creation Context root:system_r:initrc_t Assigned
Jun 28 01:30:17 192.168.137.1 login: pam_selinux(login:session): set
root key creation context to root:system_r:initrc_t


Can someone PLEASE help me understand why login processes is not being
allowed to transition to /bin/sh and what do I need to do fix this?

Regards,
-Sam

--
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.

Re: login process unable to execute /bin/sh

[Guido Trentalancia]

Hello Sam !

At a very first sight, I have spotted something...

On 27/06/2011 17:44, Sam Gandhi wrote:
> I have labelled login and sh as shown below.
>
> -rwxr-xr-x    1     25024 Jun 24 22:20 system_u:object_r:login_exec_t
>   /bin/login
> -rwxr-xr-x    1          15 Jun 24 18:40 system_u:object_r:bin_t
>     /bin/sh
>
> Following is output of ps -Z
>        1 system_u:system_r:init_t         S    init
>    583 system_u:system_r:local_login_t  S    login -- root
>
> But when I login I see these messages :
>
> Jan  1 10:00:23 192.168.137.1 kernel: type=1400 audit(23.040:40): avc:
>   granted  { transition } for  pid=596 comm="getty" path="/bin/login"
> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
> tcontext=system_u:system_r:local_login_t tclass=process

This is one way, granted.

> Jun 28 01:30:17 192.168.137.1 kernel: type=1400
> audit(1309188617.348:46): avc:  denied  { transition } for  pid=833
> comm="login" path="/bin/sh" dev=ubifs ino=93
> scontext=system_u:system_r:local_login_t
> tcontext=root:system_r:initrc_t tclass=process

Now this is the other way, there's no rule !

> I do see following statement in policy.conf (monolithic)
>
> allow local_login_t initrc_t:process transition;

Perhaps, you should try adding the other rule ?

allow initrc_t local_login_t:process transition;

[cut]

> Can someone PLEASE help me understand why login processes is not being
> allowed to transition to /bin/sh and what do I need to do fix this?
>
> Regards,
> -Sam

Hope it helps.

Regards,

Guido

--
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.

Re: login process unable to execute /bin/sh

[Sam Gandhi]

Hello Guido,

On Mon, Jun 27, 2011 at 9:47 AM, Guido Trentalancia
<guido@trentalancia.com> wrote:
> Hello Sam !
>
> At a very first sight, I have spotted something...
>
> On 27/06/2011 17:44, Sam Gandhi wrote:
>>
>> I have labelled login and sh as shown below.
>>
>> -rwxr-xr-x    1     25024 Jun 24 22:20 system_u:object_r:login_exec_t
>>  /bin/login
>> -rwxr-xr-x    1          15 Jun 24 18:40 system_u:object_r:bin_t
>>    /bin/sh
>>
>> Following is output of ps -Z
>>       1 system_u:system_r:init_t         S    init
>>   583 system_u:system_r:local_login_t  S    login -- root
>>
>> But when I login I see these messages :
>>
>> Jan  1 10:00:23 192.168.137.1 kernel: type=1400 audit(23.040:40): avc:
>>  granted  { transition } for  pid=596 comm="getty" path="/bin/login"
>> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
>> tcontext=system_u:system_r:local_login_t tclass=process
>
> This is one way, granted.
>
>> Jun 28 01:30:17 192.168.137.1 kernel: type=1400
>> audit(1309188617.348:46): avc:  denied  { transition } for  pid=833
>> comm="login" path="/bin/sh" dev=ubifs ino=93
>> scontext=system_u:system_r:local_login_t
>> tcontext=root:system_r:initrc_t tclass=process
>
> Now this is the other way, there's no rule !
>
>> I do see following statement in policy.conf (monolithic)
>>
>> allow local_login_t initrc_t:process transition;
>
> Perhaps, you should try adding the other rule ?
>
> allow initrc_t local_login_t:process transition;

I already have the above rule in the policy.

Jan  1 10:00:37 192.168.137.1 kernel: type=1400 audit(37.230:44): avc:
 granted  { transition } for  pid=600 comm="getty" path="/bin/login"
dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
tcontext=system_u:system_r:local_login_t tclass=process

Am I wrong in assuming that getty is not an issue because audit
message indicates that when getty executed program /bin/login , domain
transition was done successfully to local_login_t

Jan  1 10:00:39 192.168.137.1 kernel: type=1400 audit(39.090:45): avc:
 denied  { transition } for  pid=812 comm="login" path="/bin/sh"
dev=ubifs ino=93 scontext=system_u:system_r:local_login_t
tcontext=root:system_r:initrc_t tclass=process

One more piece of information I didn't include in previous email was,
/bin/sh is labeled as shell_exec_t and I do see following rules in my
policy.conf.

type_transition initrc_t shell_exec_t:process initrc_t;
allow initrc_t shell_exec_t:file { read { getattr execute } Ballow
initrc_t shell_exec_t:file { read getattr lock execute ioctl };
allow initrc_t shell_exec_t:file entrypoint;

allow local_login_t shell_exec_t:file { read { getattr execute } };
type_transition local_login_t shell_exec_t:process initrc_t;
allow local_login_t shell_exec_t:file { read { getattr execute } };
allow local_login_t shell_exec_t:file { { read getattr lock execute
ioctl } execute_no_trans };
allow local_login_t shell_exec_t:file entrypoint;

The best as I understand allow rules, the local_login_t rules above
says, when process running in context local_login_t (login program in
my case) tries to execute program of type shell_exec_t it should be
allowed, and process should transition to context initrc_t (because of
type_transition statement above).

Still puzzled as to why I keep getting local_login deny message
(help!). I am running the system with  'auditallow domain
domain:process transition;'  and I don't see any other domain
transitions happening when I try to login to my system.

-Sam


--
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.

Re: login process unable to execute /bin/sh

[Russell Coker]

On Tue, 28 Jun 2011, Sam Gandhi <samgandhi9@gmail.com> wrote:
> > Perhaps, you should try adding the other rule ?
> > 
> > allow initrc_t local_login_t:process transition;

Why would that be desirable?  /bin/login is generally run from getty which is 
run from init.  Do we have a need for scripts under /etc/init.d/ to run 
/bin/login?
 
> Jan  1 10:00:37 192.168.137.1 kernel: type=1400 audit(37.230:44): avc:
>  granted  { transition } for  pid=600 comm="getty" path="/bin/login"
> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
> tcontext=system_u:system_r:local_login_t tclass=process
> 
> Am I wrong in assuming that getty is not an issue because audit
> message indicates that when getty executed program /bin/login , domain
> transition was done successfully to local_login_t

Why is getty running in initrc_t?  What label is on the getty executable and 
what is the context of the program that runs it?

> Jan  1 10:00:39 192.168.137.1 kernel: type=1400 audit(39.090:45): avc:
>  denied  { transition } for  pid=812 comm="login" path="/bin/sh"
> dev=ubifs ino=93 scontext=system_u:system_r:local_login_t
> tcontext=root:system_r:initrc_t tclass=process
> 
> One more piece of information I didn't include in previous email was,
> /bin/sh is labeled as shell_exec_t and I do see following rules in my
> policy.conf.

/bin/sh is usually a symlink (labelled as bin_t) and points to something else 
matching /bin/*sh - which should have shell_exec_t as the type.  Not that it 
matters in a normal situation.

> type_transition initrc_t shell_exec_t:process initrc_t;

That looks wrong.

> allow initrc_t shell_exec_t:file { read { getattr execute } Ballow
> initrc_t shell_exec_t:file { read getattr lock execute ioctl };
> allow initrc_t shell_exec_t:file entrypoint;
> 
> allow local_login_t shell_exec_t:file { read { getattr execute } };
> type_transition local_login_t shell_exec_t:process initrc_t;
> allow local_login_t shell_exec_t:file { read { getattr execute } };
> allow local_login_t shell_exec_t:file { { read getattr lock execute
> ioctl } execute_no_trans };
> allow local_login_t shell_exec_t:file entrypoint;
> 
> The best as I understand allow rules, the local_login_t rules above
> says, when process running in context local_login_t (login program in
> my case) tries to execute program of type shell_exec_t it should be
> allowed, and process should transition to context initrc_t (because of
> type_transition statement above).
> 
> Still puzzled as to why I keep getting local_login deny message
> (help!). I am running the system with  'auditallow domain
> domain:process transition;'  and I don't see any other domain
> transitions happening when I try to login to my system.

You shouldn't have a login session with the domain initrc_t.  You should have 
the login program tell the kernel which context to use and it should be 
something with a different domain.  Either the login program should be patched 
or you should use PAM with pam_selinux.so configured.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
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.

Re: login process unable to execute /bin/sh

[Sam Gandhi]

Hello Russell,

On Tue, Jun 28, 2011 at 6:29 AM, Russell Coker <russell@coker.com.au> wrote:
> On Tue, 28 Jun 2011, Sam Gandhi <samgandhi9@gmail.com> wrote:
>> > Perhaps, you should try adding the other rule ?
>> >
>> > allow initrc_t local_login_t:process transition;
>
> Why would that be desirable?  /bin/login is generally run from getty which is
> run from init.  Do we have a need for scripts under /etc/init.d/ to run
> /bin/login?

I have fixed this. Now getty runs in getty_t and login is in local_login_t

  611 system_u:system_r:getty_t          S    /bin/busybox /sbin/getty
-L 115200
  594 system_u:system_r:local_login_t  S    login -- root

>
>> Jan  1 10:00:37 192.168.137.1 kernel: type=1400 audit(37.230:44): avc:
>>  granted  { transition } for  pid=600 comm="getty" path="/bin/login"
>> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
>> tcontext=system_u:system_r:local_login_t tclass=process
>>
>> Am I wrong in assuming that getty is not an issue because audit
>> message indicates that when getty executed program /bin/login , domain
>> transition was done successfully to local_login_t
>
> Why is getty running in initrc_t?  What label is on the getty executable and
> what is the context of the program that runs it?
>
>> Jan  1 10:00:39 192.168.137.1 kernel: type=1400 audit(39.090:45): avc:
>>  denied  { transition } for  pid=812 comm="login" path="/bin/sh"
>> dev=ubifs ino=93 scontext=system_u:system_r:local_login_t
>> tcontext=root:system_r:initrc_t tclass=process
>>
>> One more piece of information I didn't include in previous email was,
>> /bin/sh is labeled as shell_exec_t and I do see following rules in my
>> policy.conf.
>
> /bin/sh is usually a symlink (labelled as bin_t) and points to something else
> matching /bin/*sh - which should have shell_exec_t as the type.  Not that it
> matters in a normal situation.

In my situation I am using busybox that is compiled with option
CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS=y.
hence /bin/sh  is not a link, but really a script that contains  following line

#!/bin/busybox

We decided to use option of CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS as
it will allow us to label busybox executables and may not require
approach you have suggested in your paper
http://doc.coker.com.au/papers/porting-se-linux-hand-held-devices/

>
>> type_transition initrc_t shell_exec_t:process initrc_t;
>
> That looks wrong.
>
>> allow initrc_t shell_exec_t:file { read { getattr execute } Ballow
>> initrc_t shell_exec_t:file { read getattr lock execute ioctl };
>> allow initrc_t shell_exec_t:file entrypoint;
>>
>> allow local_login_t shell_exec_t:file { read { getattr execute } };
>> type_transition local_login_t shell_exec_t:process initrc_t;
>> allow local_login_t shell_exec_t:file { read { getattr execute } };
>> allow local_login_t shell_exec_t:file { { read getattr lock execute
>> ioctl } execute_no_trans };
>> allow local_login_t shell_exec_t:file entrypoint;
>>
>> The best as I understand allow rules, the local_login_t rules above
>> says, when process running in context local_login_t (login program in
>> my case) tries to execute program of type shell_exec_t it should be
>> allowed, and process should transition to context initrc_t (because of
>> type_transition statement above).
>>
>> Still puzzled as to why I keep getting local_login deny message
>> (help!). I am running the system with  'auditallow domain
>> domain:process transition;'  and I don't see any other domain
>> transitions happening when I try to login to my system.
>
> You shouldn't have a login session with the domain initrc_t.  You should have
> the login program tell the kernel which context to use and it should be
> something with a different domain.  Either the login program should be patched
> or you should use PAM with pam_selinux.so configured.
>

I am using the latest pam_selinux for login and my pam.d/login looks like this:

session required pam_selinux.so close debug verbose
session required pam_selinux.so open nottys debug verbose
auth            sufficient      pam_unix.so shadow audit use_authtok
auth           required        pam_deny.so
account         required        pam_unix.so shadow audit use_authtok

In spite all of this I was still getting that AVC deny message from login_t

type=1400 audit(39.090:45): avc: denied  { transition } for  pid=812
comm="login" path="/bin/sh" dev=ubifs ino=93
scontext=system_u:system_r:local_login_t
tcontext=root:system_r:initrc_t tclass=process

The problem turned out to be the constraints and I have fixed the
problem by having following in my constraints file (originally I
didn't have t1 == can_change_process_identity )

Now my process transition constrains look like this:

constrain process transition
        ( u1 == u2 or t1 == privuser or t1 == can_change_process_identity );
constrain process transition
        ( r1 == r2 or t1 == privrole );
constrain process dyntransition
        ( u1 == u2 and r1 == r2);

And I have set attribute can_change_process_identity on local_login_t

typeattribute local_login_t can_change_process_identity;

Now when users login things are transitioning properly, but this kind
of sounds bit hack-ish? But I looked at monolithic policy that is
generated as part of  "reference policy" and it seems to set lot of
other flags on login_t so I suppose its right thing to do?

-Sam


--
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.

Re: login process unable to execute /bin/sh

[Russell Coker]

On Wed, 29 Jun 2011, Sam Gandhi <samgandhi9@gmail.com> wrote:
> In my situation I am using busybox that is compiled with option
> CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS=y.
> hence /bin/sh  is not a link, but really a script that contains  following
> line
> 
> #!/bin/busybox

That is a rather convoluted way of launching all the shell scripts that have 
#!/bin/sh at the start, but it probably doesn't make a noticable impact on 
performance with modern hardware.

> We decided to use option of CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS as
> it will allow us to label busybox executables and may not require
> approach you have suggested in your paper

The advantage of using a small C program as the wrapper or of having multiple 
busybox applications for different sets of utilities is to provide a reliable 
atomic domain transition.

If one of those shell scripts causes a transition into a more privileged 
domain (as could be the case for ping or traceroute if you use them) then a 
hostile party could create a symlink to the shell script in question and try a 
race condition of replacing the link while in the process of executing it.  If 
they time it right then the old version of the symlink (pointing to a system 
script) would be used for the domain transition and the new version would be 
executed.

Of course if you define the threat model for your embedded/mobile device to 
not include having user_t take over ping_t via a race condition then it could 
be OK.  It would be quite valid in some situations to define SE Linux as only 
protecting local resources and not have it restrict network access.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
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.

Re: login process unable to execute /bin/sh

[Stephen Smalley]

On Tue, 2011-06-28 at 15:06 -0700, Sam Gandhi wrote:
> Hello Russell,
> 
> On Tue, Jun 28, 2011 at 6:29 AM, Russell Coker <russell@coker.com.au> wrote:
> > On Tue, 28 Jun 2011, Sam Gandhi <samgandhi9@gmail.com> wrote:
> >> > Perhaps, you should try adding the other rule ?
> >> >
> >> > allow initrc_t local_login_t:process transition;
> >
> > Why would that be desirable?  /bin/login is generally run from getty which is
> > run from init.  Do we have a need for scripts under /etc/init.d/ to run
> > /bin/login?
> 
> I have fixed this. Now getty runs in getty_t and login is in local_login_t
> 
>   611 system_u:system_r:getty_t          S    /bin/busybox /sbin/getty
> -L 115200
>   594 system_u:system_r:local_login_t  S    login -- root
> 
> >
> >> Jan  1 10:00:37 192.168.137.1 kernel: type=1400 audit(37.230:44): avc:
> >>  granted  { transition } for  pid=600 comm="getty" path="/bin/login"
> >> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
> >> tcontext=system_u:system_r:local_login_t tclass=process
> >>
> >> Am I wrong in assuming that getty is not an issue because audit
> >> message indicates that when getty executed program /bin/login , domain
> >> transition was done successfully to local_login_t
> >
> > Why is getty running in initrc_t?  What label is on the getty executable and
> > what is the context of the program that runs it?
> >
> >> Jan  1 10:00:39 192.168.137.1 kernel: type=1400 audit(39.090:45): avc:
> >>  denied  { transition } for  pid=812 comm="login" path="/bin/sh"
> >> dev=ubifs ino=93 scontext=system_u:system_r:local_login_t
> >> tcontext=root:system_r:initrc_t tclass=process
> >>
> >> One more piece of information I didn't include in previous email was,
> >> /bin/sh is labeled as shell_exec_t and I do see following rules in my
> >> policy.conf.
> >
> > /bin/sh is usually a symlink (labelled as bin_t) and points to something else
> > matching /bin/*sh - which should have shell_exec_t as the type.  Not that it
> > matters in a normal situation.
> 
> In my situation I am using busybox that is compiled with option
> CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS=y.
> hence /bin/sh  is not a link, but really a script that contains  following line
> 
> #!/bin/busybox
> 
> We decided to use option of CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS as
> it will allow us to label busybox executables and may not require
> approach you have suggested in your paper
> http://doc.coker.com.au/papers/porting-se-linux-hand-held-devices/
> 
> >
> >> type_transition initrc_t shell_exec_t:process initrc_t;
> >
> > That looks wrong.
> >
> >> allow initrc_t shell_exec_t:file { read { getattr execute } Ballow
> >> initrc_t shell_exec_t:file { read getattr lock execute ioctl };
> >> allow initrc_t shell_exec_t:file entrypoint;
> >>
> >> allow local_login_t shell_exec_t:file { read { getattr execute } };
> >> type_transition local_login_t shell_exec_t:process initrc_t;
> >> allow local_login_t shell_exec_t:file { read { getattr execute } };
> >> allow local_login_t shell_exec_t:file { { read getattr lock execute
> >> ioctl } execute_no_trans };
> >> allow local_login_t shell_exec_t:file entrypoint;
> >>
> >> The best as I understand allow rules, the local_login_t rules above
> >> says, when process running in context local_login_t (login program in
> >> my case) tries to execute program of type shell_exec_t it should be
> >> allowed, and process should transition to context initrc_t (because of
> >> type_transition statement above).
> >>
> >> Still puzzled as to why I keep getting local_login deny message
> >> (help!). I am running the system with  'auditallow domain
> >> domain:process transition;'  and I don't see any other domain
> >> transitions happening when I try to login to my system.
> >
> > You shouldn't have a login session with the domain initrc_t.  You should have
> > the login program tell the kernel which context to use and it should be
> > something with a different domain.  Either the login program should be patched
> > or you should use PAM with pam_selinux.so configured.
> >
> 
> I am using the latest pam_selinux for login and my pam.d/login looks like this:
> 
> session required pam_selinux.so close debug verbose
> session required pam_selinux.so open nottys debug verbose
> auth            sufficient      pam_unix.so shadow audit use_authtok
> auth           required        pam_deny.so
> account         required        pam_unix.so shadow audit use_authtok
> 
> In spite all of this I was still getting that AVC deny message from login_t
> 
> type=1400 audit(39.090:45): avc: denied  { transition } for  pid=812
> comm="login" path="/bin/sh" dev=ubifs ino=93
> scontext=system_u:system_r:local_login_t
> tcontext=root:system_r:initrc_t tclass=process
> 
> The problem turned out to be the constraints and I have fixed the
> problem by having following in my constraints file (originally I
> didn't have t1 == can_change_process_identity )
> 
> Now my process transition constrains look like this:
> 
> constrain process transition
>         ( u1 == u2 or t1 == privuser or t1 == can_change_process_identity );
> constrain process transition
>         ( r1 == r2 or t1 == privrole );
> constrain process dyntransition
>         ( u1 == u2 and r1 == r2);
> 
> And I have set attribute can_change_process_identity on local_login_t
> 
> typeattribute local_login_t can_change_process_identity;
> 
> Now when users login things are transitioning properly, but this kind
> of sounds bit hack-ish? But I looked at monolithic policy that is
> generated as part of  "reference policy" and it seems to set lot of
> other flags on login_t so I suppose its right thing to do?

Or you could have just added the privuser type attribute to
local_login_t instead of changing the constraint.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: login process unable to execute /bin/sh

[Sam Gandhi]

On Fri, Jul 1, 2011 at 6:26 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2011-06-28 at 15:06 -0700, Sam Gandhi wrote:
>> Hello Russell,
>>
>> On Tue, Jun 28, 2011 at 6:29 AM, Russell Coker <russell@coker.com.au> wrote:
>> > On Tue, 28 Jun 2011, Sam Gandhi <samgandhi9@gmail.com> wrote:
>> >> > Perhaps, you should try adding the other rule ?
>> >> >
>> >> > allow initrc_t local_login_t:process transition;
>> >
>> > Why would that be desirable?  /bin/login is generally run from getty which is
>> > run from init.  Do we have a need for scripts under /etc/init.d/ to run
>> > /bin/login?
>>
>> I have fixed this. Now getty runs in getty_t and login is in local_login_t
>>
>>   611 system_u:system_r:getty_t          S    /bin/busybox /sbin/getty
>> -L 115200
>>   594 system_u:system_r:local_login_t  S    login -- root
>>
>> >
>> >> Jan  1 10:00:37 192.168.137.1 kernel: type=1400 audit(37.230:44): avc:
>> >>  granted  { transition } for  pid=600 comm="getty" path="/bin/login"
>> >> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
>> >> tcontext=system_u:system_r:local_login_t tclass=process
>> >>
>> >> Am I wrong in assuming that getty is not an issue because audit
>> >> message indicates that when getty executed program /bin/login , domain
>> >> transition was done successfully to local_login_t
>> >
>> > Why is getty running in initrc_t?  What label is on the getty executable and
>> > what is the context of the program that runs it?
>> >
>> >> Jan  1 10:00:39 192.168.137.1 kernel: type=1400 audit(39.090:45): avc:
>> >>  denied  { transition } for  pid=812 comm="login" path="/bin/sh"
>> >> dev=ubifs ino=93 scontext=system_u:system_r:local_login_t
>> >> tcontext=root:system_r:initrc_t tclass=process
>> >>
>> >> One more piece of information I didn't include in previous email was,
>> >> /bin/sh is labeled as shell_exec_t and I do see following rules in my
>> >> policy.conf.
>> >
>> > /bin/sh is usually a symlink (labelled as bin_t) and points to something else
>> > matching /bin/*sh - which should have shell_exec_t as the type.  Not that it
>> > matters in a normal situation.
>>
>> In my situation I am using busybox that is compiled with option
>> CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS=y.
>> hence /bin/sh  is not a link, but really a script that contains  following line
>>
>> #!/bin/busybox
>>
>> We decided to use option of CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS as
>> it will allow us to label busybox executables and may not require
>> approach you have suggested in your paper
>> http://doc.coker.com.au/papers/porting-se-linux-hand-held-devices/
>>
>> >
>> >> type_transition initrc_t shell_exec_t:process initrc_t;
>> >
>> > That looks wrong.
>> >
>> >> allow initrc_t shell_exec_t:file { read { getattr execute } Ballow
>> >> initrc_t shell_exec_t:file { read getattr lock execute ioctl };
>> >> allow initrc_t shell_exec_t:file entrypoint;
>> >>
>> >> allow local_login_t shell_exec_t:file { read { getattr execute } };
>> >> type_transition local_login_t shell_exec_t:process initrc_t;
>> >> allow local_login_t shell_exec_t:file { read { getattr execute } };
>> >> allow local_login_t shell_exec_t:file { { read getattr lock execute
>> >> ioctl } execute_no_trans };
>> >> allow local_login_t shell_exec_t:file entrypoint;
>> >>
>> >> The best as I understand allow rules, the local_login_t rules above
>> >> says, when process running in context local_login_t (login program in
>> >> my case) tries to execute program of type shell_exec_t it should be
>> >> allowed, and process should transition to context initrc_t (because of
>> >> type_transition statement above).
>> >>
>> >> Still puzzled as to why I keep getting local_login deny message
>> >> (help!). I am running the system with  'auditallow domain
>> >> domain:process transition;'  and I don't see any other domain
>> >> transitions happening when I try to login to my system.
>> >
>> > You shouldn't have a login session with the domain initrc_t.  You should have
>> > the login program tell the kernel which context to use and it should be
>> > something with a different domain.  Either the login program should be patched
>> > or you should use PAM with pam_selinux.so configured.
>> >
>>
>> I am using the latest pam_selinux for login and my pam.d/login looks like this:
>>
>> session required pam_selinux.so close debug verbose
>> session required pam_selinux.so open nottys debug verbose
>> auth            sufficient      pam_unix.so shadow audit use_authtok
>> auth           required        pam_deny.so
>> account         required        pam_unix.so shadow audit use_authtok
>>
>> In spite all of this I was still getting that AVC deny message from login_t
>>
>> type=1400 audit(39.090:45): avc: denied  { transition } for  pid=812
>> comm="login" path="/bin/sh" dev=ubifs ino=93
>> scontext=system_u:system_r:local_login_t
>> tcontext=root:system_r:initrc_t tclass=process
>>
>> The problem turned out to be the constraints and I have fixed the
>> problem by having following in my constraints file (originally I
>> didn't have t1 == can_change_process_identity )
>>
>> Now my process transition constrains look like this:
>>
>> constrain process transition
>>         ( u1 == u2 or t1 == privuser or t1 == can_change_process_identity );
>> constrain process transition
>>         ( r1 == r2 or t1 == privrole );
>> constrain process dyntransition
>>         ( u1 == u2 and r1 == r2);
>>
>> And I have set attribute can_change_process_identity on local_login_t
>>
>> typeattribute local_login_t can_change_process_identity;
>>
>> Now when users login things are transitioning properly, but this kind
>> of sounds bit hack-ish? But I looked at monolithic policy that is
>> generated as part of  "reference policy" and it seems to set lot of
>> other flags on login_t so I suppose its right thing to do?
>
> Or you could have just added the privuser type attribute to
> local_login_t instead of changing the constraint.
>

Oh thanks for that suggestion, I will do that. And keep the
constraints untouched.

Regards,
-Sam


--
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.

Re: login process unable to execute /bin/sh

[Kyle Moffett]

On Mon, Jun 27, 2011 at 11:44, Sam Gandhi <samgandhi9@gmail.com> wrote:
> I have labelled login and sh as shown below.
>
> -rwxr-xr-x    1     25024 Jun 24 22:20 system_u:object_r:login_exec_t
>  /bin/login
> -rwxr-xr-x    1          15 Jun 24 18:40 system_u:object_r:bin_t
>   /bin/sh
>
> Following is output of ps -Z
>      1 system_u:system_r:init_t         S    init
>  583 system_u:system_r:local_login_t  S    login -- root
>
> But when I login I see these messages :
>
> Jan  1 10:00:23 192.168.137.1 kernel: type=1400 audit(23.040:40): avc:
>  granted  { transition } for  pid=596 comm="getty" path="/bin/login"
> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
> tcontext=system_u:system_r:local_login_t tclass=process
> Jun 28 01:30:17 192.168.137.1 kernel: type=1400
> audit(1309188617.348:46): avc:  denied  { transition } for  pid=833
> comm="login" path="/bin/sh" dev=ubifs ino=93
> scontext=system_u:system_r:local_login_t
> tcontext=root:system_r:initrc_t tclass=process

I believe your "getty" process should be something like "getty_t",
not "initrc_t", so probably you have the wrong label on /sbin/getty.

I don't remember if this is quite the right command, but something
along the lines of "restorecon -RF /" followed by a reboot *should*
fix all of those issues, assuming your policy file_contexts are right.

Cheers,
Kyle Moffett


--
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.

Re: login process unable to execute /bin/sh

[Stephen Smalley]

On Mon, 2011-06-27 at 08:44 -0700, Sam Gandhi wrote:
> I have labelled login and sh as shown below.
> 
> -rwxr-xr-x    1     25024 Jun 24 22:20 system_u:object_r:login_exec_t
>  /bin/login
> -rwxr-xr-x    1          15 Jun 24 18:40 system_u:object_r:bin_t
>    /bin/sh
> 
> Following is output of ps -Z
>       1 system_u:system_r:init_t         S    init
>   583 system_u:system_r:local_login_t  S    login -- root
> 
> But when I login I see these messages :
> 
> Jan  1 10:00:23 192.168.137.1 kernel: type=1400 audit(23.040:40): avc:
>  granted  { transition } for  pid=596 comm="getty" path="/bin/login"
> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t
> tcontext=system_u:system_r:local_login_t tclass=process
> Jun 28 01:30:17 192.168.137.1 kernel: type=1400
> audit(1309188617.348:46): avc:  denied  { transition } for  pid=833
> comm="login" path="/bin/sh" dev=ubifs ino=93
> scontext=system_u:system_r:local_login_t
> tcontext=root:system_r:initrc_t tclass=process
> 
> I do see following statement in policy.conf (monolithic)
> 
> allow local_login_t initrc_t:process transition;

Constraint violation.  audit2why would have told you so.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.