The link does not work. On 01/23/2017 05:37 AM, 面和毅 wrote: > Dear, Sir, > > I just post detailed information and result on our community blog. > > https://jsosug.github.io/post/omok-selinux-20170123/ > > Kind Regards, > > OMO > > 2017-01-20 21:02 GMT+09:00 面和毅 <ka-omo@xxxxxxxx>: >> Dear Sir, >> >> Finally I found SELinux could mitigate that vulnerability. Good!! :-) >> >> I checked my PoC system status(actually re-installed fedora25 again), >> then I found that problem caused from selinux policy. >> >> policy version: selinux-policy-targeted-3.13.1-225.6.fc25.noarch >> >> I ran "runc" from shell, but it seems the policy is focusing to >> run "runc" from systemd, etc (I checked from CIL polocy). >> >> For my PoC, we need to run "runc" from shell. >> Then I needed to add localpolicy for typetransition from >> unconfined_t to container_t. >> Finally I found SELinux could prevent to cat /etc/shadow file. :-) >> >> Here is my result; >> ----------------------------------------------- >> -rwxr-xr-x. 1 root root system_u:object_r: container_runtime_exec_t:s0 >> 5016704 Jan 20 19:26 /usr/bin/runc >> >> ----------. 1 root root system_u:object_r:shadow_t:s0 1268 Oct 13 >> 07:55 /etc/shadow >> >> unconfined_u:system_r:container_t:s0-s0:c0.c1023 10721 pts/1 Sl+ >> 0:00 runc run ctr >> >> /etc/shadow permission is "000(Default)"; >> SELinux Enforcing -> Permission Denied >> SELinux Permissive -> Permission Denied >> SELinux Disabled -> Permission Denied >> >> /etc/shadow permission is "755(Modified)"; >> SELinux Enforcing -> Permission Denied >> SELinux Permissive -> Could cat /etc/shadow >> SELinux Disabled -> Could cat /etc/shadow >> >> On /var/log/audit/audit.log I found denied log; >> type=AVC msg=audit(1484911003.065:1299): avc: denied { read } for >> pid=10131 comm="cat" name="shadow" dev="dm-0" ino=785423 scontext= >> unconfined_u:system_r:container_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:shadow_t:s0 tclass=file permissive=0 >> ----------------------------------------------- >> >> Below is additional policy(because this is just >> for PoC, I only added denied permssion >> to container_t domain. Also I ran that container >> by "runc" in /tmp directory); >> >> ----------------------------------------------- >> (typetransition unconfined_usertype container_runtime_exec_t process >> container_t) >> (roletransition unconfined_r container_runtime_exec_t process system_r) >> >> (allow container_t user_tmp_t (file (open read execute execute_no_trans))) >> (allow container_t var_run_t (dir (write add_name create setattr >> remove_name rmdir))) >> (allow container_t var_run_t (fifo_file (create setattr unlink read open))) >> (allow container_t ptmx_t (chr_file (read write open ioctl))) >> (allow container_t devpts_t (chr_file (setattr read write open ioctl getattr))) >> (allow container_t root_t (dir (mounton))) >> (allow container_t user_tmp_t (dir (mounton write add_name create >> remove_name rmdir))) >> (allow container_t user_tmp_t (lnk_file (read))) >> (allow container_t proc_t (filesystem (mount remount))) >> (allow container_t tmpfs_t (filesystem (mount remount))) >> (allow container_t tmpfs_t (dir (setattr write add_name create mounton))) >> (allow container_t devpts_t (filesystem (mount))) >> (allow container_t sysfs_t (filesystem (mount))) >> (allow container_t cgroup_t (filesystem (remount))) >> (allow container_t tmpfs_t (lnk_file (create))) >> (allow container_t tmpfs_t (chr_file (create setattr read write open >> getattr ioctl append))) >> (allow container_t tmpfs_t (file (open create mounton))) >> (allow container_t proc_t (dir (mounton))) >> (allow container_t proc_t (file (mounton))) >> (allow container_t sysctl_irq_t (dir (mounton))) >> (allow container_t sysctl_t (dir (mounton))) >> (allow container_t sysctl_t (file (mounton))) >> (allow container_t proc_kcore_t (file (mounton))) >> (allow container_t nsfs_t (file (getattr read open))) >> (allow container_t var_run_t (file (create read write open unlink))) >> (allow container_t sysfs_t (dir (mounton))) >> (allow container_t kernel_t (unix_stream_socket (read write))) >> (allow init_t kernel_t (unix_stream_socket (read write))) >> (allow container_t init_t (unix_stream_socket (read write))) >> ----------------------------------------------- >> >> I'll also post this result on our community blog. >> >> Kind Regards, >> >> OMO >> >> 2017-01-19 23:06 GMT+09:00 Daniel J Walsh <dwalsh@xxxxxxxxxx>: >>> You are not testing with SELinux if it can read /etc/shadow. The >>> process should be running as container_t or svirt_lxc_net_t if it is an >>> older version. >>> >>> >>> We currently label runc as container_runtime_exec_t. >>> >>> dnf reinstall container-selinux >>> >>> ls -lZ /usr/sbin/runc >>> >>> >>> >>> On 01/19/2017 02:56 AM, 面和毅 wrote: >>>> Dear Sir, >>>> >>>> Thanks. I was checking can we cat /etc/shadow in my testing environment. >>>> It seems that is protected because that file's permission is set to "000". >>>> >>>> Here is my test result; >>>> -------------------------------------------------------------- >>>> ----------. 1 root root system_u:object_r:shadow_t:s0 >>>> 1268 Oct 13 07:55 /etc/shadow >>>> >>>> SELinux Enforcing -> Permission Denied >>>> SELinux Permissive -> Permission Denied >>>> SELinux Disabled -> Permission Denied >>>> >>>> When I changed that permission to "755"; >>>> >>>> SELinux Enforcing -> Could cat /etc/shadow >>>> SELinux Permissive -> Could cat /etc/shadow >>>> SELinux Disabled -> Could cat /etc/shadow >>>> >>>> Then in this case that escaped user could >>>> have read access to shadow_t label. >>>> -------------------------------------------------------------- >>>> >>>> That "runc" process seems to be working as unconfined_t domain; >>>> >>>> [root@fedora25 ~]# ps axZ|grep runc >>>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1578 pts/0 Sl+ >>>> 0:00 runc run ctr >>>> >>>> So, I'm not sure but I guess we would better to assign >>>> other domain to "runc" program (no unconfined_t). >>>> >>>> Let me check if we will run "runc" in other domain. >>>> >>>> Kind Regards, >>>> >>>> OMO >>>> >>>> 2017-01-18 23:14 GMT+09:00 Daniel J Walsh <dwalsh@xxxxxxxxxx>: >>>>> On 01/18/2017 12:05 AM, 面和毅 wrote: >>>>>> Dear Sir, >>>>>> >>>>>> I'm member of Japan-SOSS SIG(Secure OSS Special >>>>>> Interest Group). >>>>>> We love SELinux(12years user) and we are promoting SELinux in Japan. >>>>>> >>>>>> >From technical interesting(we are promoting Docker >>>>>> with SELinux), we did PoC for CVE-2016-9962 on Fedora25. >>>>>> >>>>>> Then we found current SELinux(maybe policy) does not >>>>>> mitigate that vulnerability. >>>>>> >>>>>> We could reproduce that vulnerability with >>>>>> - add CAP_SYS_PTRACE to container >>>>>> - modified runc because there’s not so much race window on runc. >>>>>> then we think it's not so easy in usual situation. >>>>>> Also we couldn't reproduce it on CentOS7(latest). >>>>>> >>>>>> We posted that PoC result on our community blog. >>>>>> https://jsosug.github.io/post/omok-selinux-docker-20170118/ >>>>>> >>>>>> Also we wish to argue how can we protect this kind of >>>>>> vulnerability by using SELinux. >>>>>> >>>>>> Kind Regards, >>>>>> >>>>>> OMO >>>>> Attempt to cat /etc/shadow in your test to see the blockage. >>>>> >>>>> Here is a blog I wrote on the topic. >>>>> >>>>> http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/ >>>>> >>>> >> >> >> -- >> Kazuki Omo: ka-omo@xxxxxxxx >> OSS &Security Evangelist >> OSS Business Planning Dept. >> CISSP #366942 >> Tel: +81364015149 > > _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
