Folks, Due to site maintenance trouble, we updated that site/blog to Site: http://www.secureoss.jp Blog: http://www.secureoss.jp/post/omok-selinux-docker-20170123/ http://www.secureoss.jp/post/omok-selinux-docker-20170118/ Kind Regards, OMO 2017-01-26 5:51 GMT+09:00 面和毅 <ka-omo@xxxxxxxx>: > Dear Sir, > > Thanks. We had several site maintenance yesterday, so I guess > something is corrupted. > We'll fix them and let everyone know again. > > Kind Regards, > > OMO > > 2017-01-26 5:26 GMT+09:00 Daniel J Walsh <dwalsh@xxxxxxxxxx>: >> 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 >>> >>> >> > > > > -- > Kazuki Omo: ka-omo@xxxxxxxx > OSS &Security Evangelist > OSS Business Planning Dept. > CISSP #366942 > Tel: +81364015149 -- 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.
