Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1572192

Summary: [CRI-O] Containers created with cri-o allow non-privileged user to modify filesystem.
Product: OpenShift Container Platform Reporter: Mahesh Taru <mtaru>
Component: ContainersAssignee: Mrunal Patel <mpatel>
Status: CLOSED ERRATA QA Contact: Chuan Yu <chuyu>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.9.0CC: amurdaca, aos-bugs, chuyu, dornelas, dwalsh, fbroussy, gtedorst, jokerman, michael.morello, mikael+bugzilla.redhat, mmccomas, mpatel, mtaru, pdwyer, scheng, vgoyal, xtian
Target Milestone: ---   
Target Release: 3.9.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-06 15:46:20 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:
Bug Depends On:    
Bug Blocks: 1186913    
Attachments:
Description Flags
Example none

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