LOGIN service not working on CentOS 7 (SELinux)

[KLuka]

On CentOS 7 shellinabox cannot properly execute /bin/login and we get login -- <user>: no shell: Permission denied error message displayed in browser...

This is probably related to SELinux policy. Here is the diff of SELinux config for shellinaboxd process:

• CentOS 6: system_u:system_r:initrc_t:s0
• CentOS 7: system_u:system_r:unconfined_service_t:s0

Additional info in #334, #327...

[BenjiWiebe]

@KLuka It appears that in the default SELinux setting on CentOS 7, a process with a SELinux setting of unconfined_service_t should not be restricted by SELinux in any way.

[BenjiWiebe]

@KLuka I can confirm this bug, with a fresh install of CentOS 7.

localhost login: benji
Password:
Last login: Mon Aug 31 21:04:13 on :0
login -- benji: no shell: Permission denied
Session closed.

Also, it works fine after running setenforce 0—it is a SELinux issue.

[BenjiWiebe]

@KLuka I'd be willing to work on writing a SELinux policy, except I don't have a clue where to start. This is my first run-in with SELinux. What are your thoughts?

[KLuka]

It appears that in the default SELinux setting on CentOS 7, a process with a SELinux setting of unconfined_service_t should not be restricted by SELinux in any way.

I guess that in not the case with shellinabox 😄

I'd be willing to work on writing a SELinux policy, except I don't have a clue where to start.

I also don't have a clue what to do here. I searched about this stuff all over the internet, but I didn't get any useful results... Maybe it would be useful to examine polices of other programs that use /bin/login and /bin/bash. Perhaps sshd or something alike...

I also asked Fedora package maintainer @scaronni for some help. Anyway I welcome any information regarding this issue here...

[scaronni]

I will write down the policy for a subsequent update to 2.18. I need to fix a few things on other packages before looking into this one.

[KLuka]

OK, there is no rush. For now I managed to get LOGIN service to work as expected without disabling SELinux. I guess that this is a temporary workaround.

I found some useful resources in article about nginx with SELinux.

First I created SELinux policy from errors in /var/log/audit/audit.log and with audit2allow utility. After you get login error, you can find its SELinux error description in log file ("avc: denied { transition }"). You have to pass this error to audit2allow utility and it will create SELinux policy:

grep <ERROR ID> /var/log/audit/audit.log | audit2allow -M shellinabox_workaround

After that you need to load created policy:

semodule -i shellinabox_workaround.pp

At this point LOGIN service should start working as expected...

PS: I don't know, if this is a correct workaround and how it affects overall system security. Or even if/how it can be included in RPM? I am adding policy in text format, if anyone has any clue on how to use this for more general fix/workaround.

module shellinabox_workaround 1.0;

require {
        type unconfined_t;
        type unconfined_service_t;
        class process transition;
}

#============= unconfined_service_t ==============
allow unconfined_service_t unconfined_t:process transition;

[BenjiWiebe]

@KLuka From what I've read about SELinux, I would say that is not a correct solution. That just says allow any unspecified program to run /bin/login and who knows what else (what is transition?)

Looking at your workaround, though, is helpful to me understanding how to create new policies. I might work on it yet.

[KLuka]

@BenjiWiebe you are probably correct. I just posted this so we can continue with the search for proper fix 😉

I don't know what exactly is transition as this policy is auto generated. I think that /bin/login needs to change SELinux context when /usr/bin/bash is started or something...

Here are log messages on what happens without a workaround:

type=USER_LOGIN msg=audit(1441126324.231:541): pid=2579 uid=0 auid=1000 ses=9 subj=system_u:system_r:unconfined_service_t:s0 msg='op=login id=1000 exe="/usr/bin/login" hostname=192.168.1.100 addr=192.168.1.100 terminal=pts/2 res=success'
type=AVC msg=audit(1441126324.240:542): avc:  denied  { transition } for  pid=2583 comm="login" path="/usr/bin/bash" dev="dm-0" ino=8927228 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
type=SYSCALL msg=audit(1441126324.240:542): arch=c000003e syscall=59 success=no exit=-13 a0=12d2f41 a1=7fff8e8d1d28 a2=12d6ee0 a3=7fff8e8d1870 items=0 ppid=2579 pid=2583 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=9 comm="login" exe="/usr/bin/login" subj=system_u:system_r:unconfined_service_t:s0 key=(null)

And here with workaround:

type=USER_LOGIN msg=audit(1441125984.926:520): pid=2532 uid=0 auid=1000 ses=7 subj=system_u:system_r:unconfined_service_t:s0 msg='op=login id=1000 exe="/usr/bin/login" hostname=192.168.1.100 addr=192.168.1.100 terminal=pts/1 res=success'

[claneys]

shellinabox.tar.gz
Got something working but not satisfying, I think it miss something but don't know why. Don't understand we need to use unconfined context with login.

Anyway, if it can help you in something, here is an archive with source selinux policy.

[claneys]

There are now, only 2 AVC left. Allow rules are already set in policy module but that drops Constraint rule exceptions... I don't know how to do to get rid of those errors... Shellinabox works with that policy but it is annoying since transition with unconfined context can be a security hole.

#!!!! This avc is a constraint violation.  You would need to modify the attributes of either the source or target types to allow this access.
#Constraint rule:
#       constrain chr_file { create relabelfrom relabelto } ((u1 == u2 -Fail-)  or (t1 == can_change_object_identity -Fail-) ); Constraint DENIED

#       Possible cause is the source user (system_u) and target user (unconfined_u) are different.
allow shellinaboxd_t devpts_t:chr_file relabelto;

#!!!! The file '/usr/bin/bash' is mislabeled on your system.
#!!!! Fix with $ restorecon -R -v /usr/bin/bash
#!!!! This avc is a constraint violation.  You would need to modify the attributes of either the source or target types to allow this access.
#Constraint rule:
#       constrain process { transition noatsecure siginh rlimitinh dyntransition } ((u1 == u2 -Fail-)  or (t1 == can_change_process_identity -Fail-)  and (t2 == process_user_target)  or (t1 == cron_source_domain -Fail-)  and (t2 == cron_job_domain -Fail-)  or (u2 == system_u -Fail-)  or (t1 == can_system_change -Fail-)  and (u2 == system_u -Fail-)  or (t1 == process_uncond_exempt -Fail-) ); Constraint DENIED

#       Possible cause is the source user (system_u) and target user (unconfined_u) are different.
#       Possible cause is the source role (system_r) and target role (unconfined_r) are different.
allow shellinaboxd_t unconfined_t:process transition;

[KLuka]

Hi @claneys, thanks for posting this. If I understand things correctly script shellinaboxd.sh should correctly build and load SELinux policy? If that is the case I welcome you to create a PR with this script ;)

[claneys]

Ok, here the selinux policy POC :)

[BenjiWiebe]

@KLuka Long time no see. 😉 With @claneys SELinux policy, and the "TODO: Unconfined context misuse", what's the status of that? Should a new bug be opened with that info? Because I don't feel comfortable leaving that as is, especially since Fedora is using this as upstream now.

[sandeepksaini]

@BenjiWiebe @KLuka

Disabling SELinux is not the suggested way. However, the fix to the problem you can run below mentioned commands:

audit2allow -a -M login
semodule -i login.pp

Refer to my blog for same:
https://cloudspanner.wordpress.com/2018/04/03/give-your-linux-shell-a-html-life-shellinabox/

[claneys]

@BenjiWiebe I'm not an expert in SELinux but I think that if you change the SELinux User for shellinaboxd binary to system_u which is meant to system's service then it should be enough.

chcon -u system_u /usr/sbin/shellinaboxd

Could you test on your platform ?

[abdennour]

This comment resolved my issue.

[df7cb]

@claneys: system_u doesn't help, it's already system_u by default on CentOS 7.

Generally, could we have a new release with the fixes from #394 ?