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

Aw: Re: Security implications of "runAsUser: type: RunAsAny"



Hello

Mr. Walsh, I am including you into this conversation because I am hoping that you can help us here. I would be very happy if you gave us your opinion.

@ccoleman:
I'm not sure we understand each other. If I give non-root users access to the docker socket, they can do this:
docker run -ti --privileged -v /:/host fedora chroot /host
and then they can mess with the system. That's one of the things we don't want.
 
Now with OpenShift the users in "oc edit scc" that fall into the Security Context Constraint "restricted" aren't even able to start privileged containers (allowPrivilegedContainer: false) and they're unable to mount any paths from the host (allowHostDirVolumePlugin: false). That's pretty awesome and an excellent additional security layer.

I am interested in 2 things:
1. Obscure stuff that is potentially dangerous. Like the article from Mr. Walsh you linked. Thankfully I'm not using Kerberos so I shouldn't be affected by this.
2. Obvious stuff that I have missed. Docker already prevents the containers from accessing sensitive devices like /dev/mem or /dev/sd* and stuff like /proc/sys and /sys is read-only. If, on top of that, the OpenShift users can only mount the stuff I allow them to mount via PhysicalVolumes and if they can't mount/access paths from the host then that should be enough additional isolation to allow them to run processes inside a container as root.
That is asuming that I haven't missed something important and there aren't many more leaky things like the kernel keyrings. Are there?
 
Regards
v
 
Gesendet: Dienstag, 27. Oktober 2015 um 22:44 Uhr
Von: "Clayton Coleman" <ccoleman redhat com>
An: v <vekt0r7 gmx net>
Cc: users <users lists openshift redhat com>
Betreff: Re: Security implications of "runAsUser: type: RunAsAny"
As root, you have access to some of the kernel devices. Generally
that means you can do *anything* to the system because a number of
core kernel resources are not namespaced. A good example is
http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/

Some of this will be improved once user namespaces land in Docker, but
until then being able to run as uid 0 (root) inside a container is
basically giving your users access to run as root on the host machine.


On Tue, Oct 27, 2015 at 5:32 PM, v <vekt0r7 gmx net> wrote:
> Hey
>
> Could you give me an example of the dangerous things that people could do to the nodes in my cluster with "type: RunAsAny"?
>
> I am not sure how much nasty stuff people could do with that. We should have SELinux type enforcement and MCS labels to keep the pods in check.
>
> regards
> v
>
> Am 2015-10-27 um 17:44 schrieb Clayton Coleman:
>> If you relax restricted for all users, then yes, anyone who can oc
>> login can run as root on your cluster.
>>
>> On Tue, Oct 27, 2015 at 12:21 PM, "Gerhard Müller" <vekt0r7 gmx net> wrote:
>>> Hello
>>>
>>> I am trying to understand the security implications of doing "oc edit scc"
>>> and using
>>> runAsUser:
>>> type: RunAsAny
>>> for "name: restricted".
>>>
>>> This makes it possible for pods in openshift to have processes inside them
>>> that run as root. If I set this for "name: restricted" most of the
>>> containers from docker.io will run in OpenShift... which is very useful.
>>> Will the people who login to the cluster via "oc login" be able to do funny
>>> things if the restricted pods have "type: RunAsAny"?
>>>
>>> regards
>>> v
>>>
>>> _______________________________________________
>>> users mailing list
>>> users lists openshift redhat com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>> _______________________________________________
>> users mailing list
>> users lists openshift redhat com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
> _______________________________________________
> users mailing list
> users lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users

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