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:
THe only way this would happen is if the /etc directory had permissions 770 root root Does it? in the cri-o container case?
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.
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
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
(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
Vivek any idea what is going on here? Perhaps uid=10000000 has DAC_OVERRIDE?
Can you paste the output of cat /proc/self/status inside the container?
(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$
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?
(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$
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.
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
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