Re: New Blog on how SELinux blocked Docker container escape.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux