Bug 1138601 - (namespace_keyring) Kernel keyring needs to be namespaced to work with containers
Kernel keyring needs to be namespaced to work with containers
Status: NEW
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Howells
Fedora Extras Quality Assurance
abrt_hash:99f186e8f51c34f2c0a2f6382f5...
: FutureFeature, Reopened
: 1260073 (view as bug list)
Depends On:
Blocks: 1142480
  Show dependency treegraph
 
Reported: 2014-09-05 05:41 EDT by Yajo
Modified: 2016-09-28 10:57 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-26 07:40:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yajo 2014-09-05 05:41:39 EDT
Description of problem:
Using `su` in a docker container.
SELinux is preventing /usr/bin/su from 'search' accesses on the key .

*****  Plugin catchall (100. confidence) suggests   **************************

If cree que de manera predeterminada, su debería permitir acceso search sobre   key.     
Then debería reportar esto como un error.
Puede generar un módulo de política local para permitir este acceso.
Do
permita el acceso momentáneamente executando:
# grep su /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:svirt_lxc_net_t:s0:c570,c723
Target Context                system_u:system_r:svirt_lxc_net_t:s0:c797,c933
Target Objects                 [ key ]
Source                        su
Source Path                   /usr/bin/su
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           util-linux-2.24.2-1.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-182.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.15.10-201.fc20.x86_64 #1 SMP Wed
                              Aug 27 21:10:06 UTC 2014 x86_64 x86_64
Alert Count                   1
First Seen                    2014-09-05 11:35:59 CEST
Last Seen                     2014-09-05 11:35:59 CEST
Local ID                      89d1327a-b517-4775-b922-28e3a3029922

Raw Audit Messages
type=AVC msg=audit(1409909759.34:600): avc:  denied  { search } for  pid=9966 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c570,c723 tcontext=system_u:system_r:svirt_lxc_net_t:s0:c797,c933 tclass=key


type=SYSCALL msg=audit(1409909759.34:600): arch=x86_64 syscall=keyctl success=no exit=EACCES a0=0 a1=fffffffd a2=0 a3=7f09456422e0 items=0 ppid=9956 pid=9966 auid=4294967295 uid=999 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm=su exe=/usr/bin/su subj=system_u:system_r:svirt_lxc_net_t:s0:c570,c723 key=(null)

Hash: su,svirt_lxc_net_t,svirt_lxc_net_t,key,search

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.15.10-201.fc20.x86_64
type:           libreport
Comment 1 Daniel Walsh 2014-09-07 07:51:31 EDT
This looks like a keyring was created within one container and it still exists when you create the new keyring.  I guess we should don't audit this.

Without SELinux this is a way for one container to attack another.  I wonder if Kernel Keyring should be namespaced and part of the IPC namespace?
Comment 2 Daniel Walsh 2014-09-07 07:53:57 EDT
692065bdda15a78937f670f2583870513ca9c27c adds a dontaudit rule to git for SELinux  but I want to leave this open for a kernel discussion.
Comment 3 Lukas Vrabec 2014-09-08 05:21:13 EDT
Backported to F20. Leaving open as Dan said.

commit e9777b479541b2e7f077bcffa26b8c1ffbe1d0c6
Author: Lukas Vrabec <lvrabec@redhat.com>
Date:   Mon Sep 8 11:19:44 2014 +0200

    Kernel will leak keyrings into different namespaces,we need to don't audit searches and block containers from using other keyrings. Hopefully the code will create a new keyring. (#1138601)

https://github.com/selinux-policy/selinux-policy/commit/e9777b479541b2e7f077bcffa26b8c1ffbe1d0c6
Comment 4 Justin M. Forbes 2014-11-13 10:55:01 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.
Comment 5 Yajo 2014-11-19 11:19:20 EST
Seems to have been fixed in my machine.
Comment 6 Daniel Walsh 2014-11-19 14:05:53 EST
What seems to be fixed?  Sharing the same kernel keyring between containers?
Comment 7 Yajo 2014-11-21 03:32:59 EST
(In reply to Daniel Walsh from comment #6)
> What seems to be fixed?  Sharing the same kernel keyring between containers?

Sorry, I don't understand the technical data given above, but I ran this without SELinux warnings:

docker run -it --rm centos bash
[root@b061f4190539 /]# adduser test
[root@b061f4190539 /]# su test
[test@b061f4190539 /]$ whoami
test
Comment 8 Daniel Walsh 2014-11-21 08:05:37 EST
That does not show the leakage of a kernel keyring from one container to another.

The problem here is creating a kernel keyring outside of the container or in one container, then attempt to use the same keyring in another container.

When you create a kernel keyring, it gets the label of the process that creates it.  svirt_lxc_net_t:s0:c1,c2  But since this is not namespaced the keyring is per UID/Session.  When I go into a different container with the same UID/Session, the same keyring will be used but the processes will be used with a different SELinux label, svirt_lxc_net_t:s0:c3,c4.  SELinux will block the access as it should.

Ignoring the SELinux issue, if I put secrets into a kernel keyring, and then run a different container, and SELinux is disabled.  The second container would be allowed to read the secrets.  Nothing other then SELinux would block the access. So this is a huge information leak of supposedly secure data.
Comment 9 Yajo 2014-11-24 11:16:10 EST
(In reply to Daniel Walsh from comment #8)

I'm sorry. You explained it very well but SELinux seems somehow black magic to me.

If I can help any further, just tell me how. :)
Comment 10 Daniel Walsh 2014-11-24 11:17:38 EST
Ok, as long as you realize SELinux is not the issue here.  Separation between containers is the issue, and SELinux is enforcing this separation.
Comment 11 Yajo 2014-11-26 12:09:38 EST
(In reply to Daniel Walsh from comment #10)
> Ok, as long as you realize SELinux is not the issue here.  Separation
> between containers is the issue, and SELinux is enforcing this separation.

Then IMHO the SELinux assistant should be clearer in this case. Nothing there indicates this is expected behavior (at least for a normal user), nor explains the issue.

I remember having clearer interactions in the past, like when Apache tries to read ~/public_www
Comment 12 Justin M. Forbes 2015-01-27 09:58:23 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.18.3-201.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 13 Daniel Walsh 2015-01-27 10:34:31 EST
Still busted.
Comment 14 Jaroslav Reznik 2015-03-03 11:16:26 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 15 Laurent Rineau 2015-06-18 10:00:02 EDT
I know a way to reproduce a very similar AVC:

  docker run --rm fedora bash -x -c 'useradd -u 500 toto; su toto -c "date"'

The "500" in the command line has to be the ID of a user that is logged into the host system: that user has a user session, with something in the keyring.

type=SYSCALL msg=audit(1434635116.397:6516474): arch=c000003e syscall=250 success=no exit=-13 a0=0 a1=fffffffd a2=0 a3=7fa8c602b310 items=0 ppid=16928 pid=17248 auid=4294967295 uid=500 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="su" exe="/usr/bin/su" subj=system_u:system_r:svirt_lxc_net_t:s0:c51,c1016 key=(null)
type=AVC msg=audit(1434635116.397:6516474): avc:  denied  { search } for  pid=17248 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c51,c1016 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
Comment 16 Laurent Rineau 2015-06-18 10:03:50 EDT
If you want to dontaudit those AVC, here is the full list, in permissive mode:

$ sudo semanage permissive -a svirt_lxc_net_t


$ docker run --rm fedora bash -x -c 'useradd -u 500 toto; su toto -c "date"'
+ useradd -u 500 toto
+ su toto -c date
Thu Jun 18 10:01:37 EDT 2015


$ sudo ausearch  -m AVC -ts recent
----
time->Thu Jun 18 16:01:20 2015
type=SYSCALL msg=audit(1434636080.720:6517286): arch=c000003e syscall=250 success=no exit=-13 a0=0 a1=fffffffd a2=0 a3=1f5 items=0 ppid=23112 pid=23156 auid=4294967295 uid=500 gid=501 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="su" exe="/bin/su" subj=system_u:system_r:svirt_lxc_net_t:s0:c609,c968 key=(null)
type=AVC msg=audit(1434636080.720:6517286): avc:  denied  { search } for  pid=23156 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c609,c968 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
----
time->Thu Jun 18 16:01:37 2015
type=SYSCALL msg=audit(1434636097.781:6517294): arch=c000003e syscall=250 success=yes exit=0 a0=8 a1=fffffffc a2=fffffffd a3=59e9e700 items=0 ppid=23881 pid=24225 auid=4294967295 uid=500 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="su" exe="/usr/bin/su" subj=system_u:system_r:svirt_lxc_net_t:s0:c340,c823 key=(null)
type=AVC msg=audit(1434636097.781:6517294): avc:  denied  { link } for  pid=24225 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c340,c823 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=key
----
time->Thu Jun 18 16:01:37 2015
type=SYSCALL msg=audit(1434636097.781:6517293): arch=c000003e syscall=250 success=yes exit=455102970 a0=0 a1=fffffffd a2=0 a3=7f91585c2310 items=0 ppid=23881 pid=24225 auid=4294967295 uid=500 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="su" exe="/usr/bin/su" subj=system_u:system_r:svirt_lxc_net_t:s0:c340,c823 key=(null)
type=AVC msg=audit(1434636097.781:6517293): avc:  denied  { search } for  pid=24225 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c340,c823 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
Comment 17 Laurent Rineau 2015-06-18 11:23:06 EDT
audit2allow -D -M creates:

module docker-su-keyring 1.0;

require {
        type unconfined_t;
        type crond_t;
        type svirt_lxc_net_t;
        class key { search link };
}

dontaudit svirt_lxc_net_t crond_t:key search;
dontaudit svirt_lxc_net_t unconfined_t:key link;

I am testing that module. It fixes the AVC I reported with:
  docker run --rm fedora bash -x -c 'useradd -u 500 toto; su toto -c "date"'

I imagine that instead of:
  dontaudit svirt_lxc_net_t crond_t:key search
  dontaudit svirt_lxc_net_t unconfined_t:key link;
it should be something using wildcards:
  dontaudit svirt_lxc_net_t *:key search
  dontaudit svirt_lxc_net_t *:key link;
but I do not know how to express that in the SELinux module langage.
Comment 18 Daniel Walsh 2015-06-18 11:34:51 EDT
I just added something like


policy_module(docker-su-keyring, 1.0)

gen_require ('
   attribute domain;
   type svirt_lxc_net_t;
')

dontaudit svirt_lxc_net_t domain:key {search link};

make -f /usr/share/selinux/devel/Makefile docker-su-keyring.pp
semodule -i docker-su-keyring.pp
Comment 19 Laurent Rineau 2015-06-18 11:40:20 EDT
(In reply to Daniel Walsh from comment #18)
> I just added something like
> 
> 
> policy_module(docker-su-keyring, 1.0)
> 
> gen_require ('
>    attribute domain;
>    type svirt_lxc_net_t;
> ')
> 
> dontaudit svirt_lxc_net_t domain:key {search link};
> 
> make -f /usr/share/selinux/devel/Makefile docker-su-keyring.pp
> semodule -i docker-su-keyring.pp

I tried that on CentOS 7 and I have:
Compiling targeted local-docker-su-keyring2 module
/usr/bin/checkmodule:  loading policy configuration from tmp/local-docker-su-keyring2.tmp
local-docker-su-keyring2.te":3:ERROR 'syntax error' at token '}' on line 3176:

Sorry I cannot do more than report my compilation error. I am too ignorant of the module language.
Comment 20 Daniel Walsh 2015-06-18 11:44:38 EDT
policy_module(docker-su-keyring, 1.0)

gen_require(`
   attribute domain;
   type svirt_lxc_net_t;
')

dontaudit svirt_lxc_net_t domain:key {search link};
Comment 21 Laurent Rineau 2015-06-19 08:09:10 EDT
(In reply to Daniel Walsh from comment #20)
> policy_module(docker-su-keyring, 1.0)
> 
> gen_require(`
>    attribute domain;
>    type svirt_lxc_net_t;
> ')
> 
> dontaudit svirt_lxc_net_t domain:key {search link};

That one worked, on my CentOS 7. I no longer have the AVC. Thanks.
Comment 22 Daniel Walsh 2015-09-04 11:25:32 EDT
*** Bug 1260073 has been marked as a duplicate of this bug. ***
Comment 23 Justin M. Forbes 2015-10-20 15:17:21 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.
Comment 24 Laura Abbott 2016-09-23 15:20:27 EDT
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.
Comment 25 Yajo 2016-09-26 03:25:22 EDT
I'm on F24 now.

I ran test suggested in comment 16:

$ docker run --rm fedora bash -x -c 'useradd -u 500 toto; su toto -c "date"'
+ useradd -u 500 toto
+ su toto -c date
Mon Sep 26 07:23:58 UTC 2016

$ sudo ausearch  -m AVC -ts recent
[sudo] password for yajo: 
<no matches>

So, it seems fixed...
Comment 26 Daniel Walsh 2016-09-26 09:56:24 EDT
I don't believe that these keyrings have been namespaced other then in the user namespace.

Note You need to log in before you can comment on or make changes to this bug.