Bug 1169149

Summary:	openssh sshd runs itself the unconfined_t SELinux security domain
Product:	[Fedora] Fedora	Reporter:	dac.override
Component:	openssh	Assignee:	Petr Lautrbach <plautrba>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jjelen, mattias.ellert, mgrepl, plautrba, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-02 12:30:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description dac.override 2014-11-30 19:21:48 UTC

Description of problem:

sshd (temporarily) runs itself in the unconfined_t SELinux security domain if you log in as root with a stock fedora system.

Version-Release number of selected component (if applicable):

any

How reproducible:

cat >> mytest <<EOF
policy_module(mytest, 1.0.0)
gen_require(\` type unconfined_t; ')
auditallow unconfined_t self:process setexec;
EOF

make -f /usr/share/selinux/devel/Makefile mytest.pp
sudo semodule -i mytest.pp

log in as root with ssh

look in the audit.log for avc granted message

You should see a granted message.

See the comm="" field of the message. It should say "sshd"
See the scontext="" field of them essage. It should say "unconfined_i:unconfined_r:unconfined_t:s0-s0:c1023"

This proves that sshd atleast for a short while runs in the SELinux unconfined_t security domain

Actual results:

sshd runs unrestricted/unprotected

Expected results:

sshd runs restricted/protected

Comment 1 Jakub Jelen 2015-03-02 12:26:32 UTC

You can see this also in pstree.

I don't think this is a bug, but feature. Even if you run ssh with non-root user, you get such pstree:

  ├─sshd,`system_u:system_r:sshd_t:s0-s0:c0.c1023' -D
  │   └─sshd,`system_u:system_r:sshd_t:s0-s0:c0.c1023'   
  │       └─sshd,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023'    
  │           └─bash,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023'
  │               └─pstree,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' -aZh

which can be explained this way:
->(daemon)
  ->(privileged monitor)
    ->(user restricted child)
      ->(bash ...)

which is comparable to normal login session, but you miss the sshd server and monitor below:

  ├─login,`system_u:system_r:local_login_t:s0-s0:c0.c1023'     
  │   └─bash,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023'
  │       └─pstree,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' -aZh

You have got "privileged" monitor, but child process is restricted by target user access rights. If it is root, you can't restrict it anyway. It is just unrestricted session.

Comment 2 Tomas Mraz 2015-03-02 12:30:18 UTC

Yes, to change the context for the user session, the sshd process must be unrestricted.