Bug 1572192 - [CRI-O] Containers created with cri-o allow non-privileged user to modify filesystem.
Summary: [CRI-O] Containers created with cri-o allow non-privileged user to modify fil...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Containers
Version: 3.9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.9.z
Assignee: Mrunal Patel
QA Contact: Chuan Yu
URL:
Whiteboard:
Depends On:
Blocks: 1186913
TreeView+ depends on / blocked
 
Reported: 2018-04-26 11:51 UTC by Mahesh Taru
Modified: 2018-06-06 15:47 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-06 15:46:20 UTC
Target Upstream Version:


Attachments (Terms of Use)
Example (24.19 KB, image/jpeg)
2018-04-27 12:32 UTC, Mikael B
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3424911 0 None None None 2018-04-26 12:09:16 UTC
Red Hat Product Errata RHBA-2018:1796 0 None None None 2018-06-06 15:47:23 UTC

Description Mahesh Taru 2018-04-26 11:51:16 UTC
Description of problem:
OCP3.9 installed with cri-o runtime allows non-root users to modify filesystem inside containers. i.e non-root user can wipe entire filesystem of container.

OCP with docker do not allow non-root user to alter container filesystem.

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


How reproducible:
Always

Steps to Reproduce:
1. Install OCP 3.9 + CRI-O using variable "openshift_use_crio=true" in inventory.
2. Post installation login to any pod.
*************************
# oc rsh docker-registry-1-xxxx
sh-4.2$ id
uid=1000000000 gid=0(root) groups=0(root),1000000000
sh-4.2$ rm -rf /etc/passwd
sh-4.2$ ls /etc/passwd  
ls: cannot access /etc/passwd: No such file or directory
*************************
3. On OCP with Docker the output is as below and is expected.
*************************
# oc rsh docker-registry-1-xxxx
sh-4.2$ id
uid=1000000000 gid=0(root) groups=0(root),1000000000
sh-4.2$ rm -rf /etc/passwd
rm: cannot remove '/etc/passwd': Permission denied
*************************

Actual results:
Able remove/modify filesystem inside container.

Expected results:
non-root user should not be able to remove/modify filesystem inside containers.

Additional info:

Comment 1 Daniel Walsh 2018-04-27 10:43:48 UTC
THe only way this would happen is if the /etc directory had permissions 

770 root root

Does it? in the cri-o container case?

Comment 2 Mikael B 2018-04-27 12:27:14 UTC
I don't have the environment right now but I had made the following test (I still have the screenshot, I'll try to attach it), as non-root user:

% cd /
% touch FILE
% ls FILE
("FILE" exists)

We also could "rm -rf /" successfully.

We can try to reproduce if needed.

Comment 3 Mikael B 2018-04-27 12:32:04 UTC
Created attachment 1427647 [details]
Example

Root FS modification from a non-root user.

Environmnent set up with CRI-O engine, with openshift-ansible. OCP v3.9.14

Comment 4 Mikael B 2018-04-27 12:35:34 UTC
Another example (but with Openshift Origin, same version v3.9.14):

sh-4.2$ ls -ald /etc/
drwxr-xr-x. 1 root root 56 Apr 27 12:29 /etc/
sh-4.2$ ls -al /etc/passwd-
-rw-r--r--. 1 root root 630 Apr  2 18:39 /etc/passwd-
sh-4.2$ id
uid=1000000000 gid=0(root) groups=0(root),1000000000
sh-4.2$ rm -f /etc/passwd-
sh-4.2$ ls -al /etc/passwd-
ls: cannot access /etc/passwd-: No such file or directory

Comment 5 Mikael B 2018-04-27 12:56:11 UTC
(In reply to Mikael B from comment #4)
> Another example (but with Openshift Origin, same version v3.9.14):

Sorry -- actually origin 3.9.0-1.el7.git.0.ba7faec

Comment 6 Daniel Walsh 2018-04-27 13:47:55 UTC
Vivek any idea what is going on here?

Perhaps uid=10000000 has DAC_OVERRIDE?

Comment 7 Mrunal Patel 2018-04-27 17:46:32 UTC
Can you paste the output of cat /proc/self/status inside the container?

Comment 8 Mikael B 2018-04-27 19:37:15 UTC
(In reply to Mrunal Patel from comment #7)
> Can you paste the output of cat /proc/self/status inside the container?

Yes:

% oc -n openshift-web-console rsh webconsole-6d75fc4f7f-dd6lp
sh-4.2$ id
uid=1000080000 gid=0(root) groups=0(root),1000080000
sh-4.2$ cd /
sh-4.2$ touch ok
sh-4.2$ ls -l ok
-rw-r--r--. 1 1000080000 root 0 Apr 27 19:27 ok
sh-4.2$
sh-4.2$ cat /proc/self/status
Name:   cat
Umask:  0022
State:  R (running)
Tgid:   2060
Ngid:   0
Pid:    2060
PPid:   1914
TracerPid:      0
Uid:    1000080000      1000080000      1000080000      1000080000
Gid:    0       0       0       0
FDSize: 256
Groups: 1000080000
VmPeak:     4336 kB
VmSize:     4336 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:       348 kB
VmRSS:       348 kB
RssAnon:              72 kB
RssFile:             276 kB
RssShmem:              0 kB
VmData:      180 kB
VmStk:       132 kB
VmExe:        44 kB
VmLib:      1892 kB
VmPTE:        32 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/31186
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 00000000a004251b
CapPrm: 00000000a004251b
CapEff: 00000000a004251b
CapBnd: 00000000a004251b
CapAmb: 00000000a004251b
Seccomp:        0
Cpus_allowed:   f
Cpus_allowed_list:      0-3
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        0
nonvoluntary_ctxt_switches:     1
sh-4.2$

Comment 9 Mrunal Patel 2018-04-30 17:19:08 UTC
It seems to have cap_dac_override. 

$ capsh --decode="00000000a004251b"
0x00000000a004251b=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_audit_write,cap_setfcap


I will check the cri-o code to see if we have any bug. 

Meanwhile, can we get the same data for docker?

Comment 10 Mikael B 2018-04-30 20:00:27 UTC
(In reply to Mrunal Patel from comment #9)
> It seems to have cap_dac_override.

Yes, nice guess.

> I will check the cri-o code to see if we have any bug.

Thanks!
 
> Meanwhile, can we get the same data for docker?

Sure, here's the same scenario with the the same installation with the docker runtime.


% oc -n openshift-web-console rsh webconsole-6d75fc4f7f-5fx5q 
sh-4.2$ id                               
uid=1000080000 gid=0(root) groups=0(root),1000080000                               
sh-4.2$ cd /                             
sh-4.2$ touch ok                                                                                                                                                       touch: cannot touch 'ok': Permission denied                                                                                                                            
sh-4.2$ ls -l ok                         
ls: cannot access ok: No such file or directory                                    
sh-4.2$                                  
sh-4.2$ cat /proc/self/status            
Name:   cat
Umask:  0022
State:  R (running)
Tgid:   739
Ngid:   0
Pid:    739
PPid:   698
TracerPid:      0
Uid:    1000080000      1000080000      1000080000      1000080000
Gid:    0       0       0       0
FDSize: 256
Groups: 1000080000
VmPeak:     4336 kB
VmSize:     4336 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:       352 kB
VmRSS:       352 kB
RssAnon:              76 kB
RssFile:             276 kB
RssShmem:              0 kB
VmData:      180 kB
VmStk:       132 kB
VmExe:        44 kB
VmLib:      1892 kB
VmPTE:        28 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/31186
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 00000000a004251b
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000a004251b
CapAmb: 0000000000000000
Seccomp:        0
Cpus_allowed:   f
Cpus_allowed_list:      0-3
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000000
0,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        1
nonvoluntary_ctxt_switches:     1
sh-4.2$

Comment 11 Mrunal Patel 2018-04-30 22:05:18 UTC
I have created https://github.com/kubernetes-incubator/cri-o/pull/1539 as a fix. It will be backported to all supported versions of cri-o.

Comment 12 fbroussy 2018-05-04 08:11:13 UTC
Hello team,
CNAM is deploying a new OCP cluster and they want to use CRI-O and not Docker. They are currently testing CRI-O
Are you able to release a patch or a hotfix for customer so they can carry on with their tests pls? many thanks

Comment 18 errata-xmlrpc 2018-06-06 15:46:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1796


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