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 _______________________________________________ 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.
