08:59:56 #startmeeting flock2016 08:59:56 Meeting started Tue Aug 2 08:59:56 2016 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:59:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 08:59:56 The meeting name has been set to 'flock2016' 09:00:17 welcome everybody, my name is Thomas Cameron, today we're talking about container security 09:00:32 Thomas -- global cloud strategy evangelist 09:00:52 what we'll be talking about today, a bit about me, a bit about rht, what containers are, how they work, what they are not 09:01:01 confusion about when to use containers 09:01:19 talk about components that make up container security, linux control groups, docker daemon, and security it provides and linux kernel capabilities 09:01:25 security enhanced linux (SELinux) 09:01:34 and tips and tricks for security and then draw some conclusions 09:01:47 been working in info technology since 1993, started my career out of school as a police officer 09:01:58 enjoy forensics, security, weird hybrid, security hybrid, 09:02:19 been with rht since 2005, rht security specialist, been in IT long enough, background in MSFT security, Novell, remember IPX SPX 09:02:45 spent a lot of time focusing on security in environments like retail, manufacturing, been at rht long enough to know there's always somebody who knows more than I do. 09:02:56 rht has been working on containeriation since 2010 09:03:21 acquired Makara, became RHT OpenShift, they had technology analguous to containers today 09:03:24 called cartridges 09:03:31 as tends to happen in open source community 09:03:50 even though we liked technology from Makara, community and insdustry showed what docker was doing made a lot of sense. 09:04:03 started participating in docker community last time I checked we were #2 contributor upstream 09:04:20 not "ooh, we're red hat" but we have a responsiblity to contribute as good stewards in open source 09:04:36 docker is doing some amazing things, many companies are all on board with container standardization 09:04:41 with docker as standard container format 09:04:54 even MSFT has announced they will support container formats 09:05:17 docker is technolgoy that allows you to have applications abstracted from and in some isolation from the underlying operating systems. 09:05:45 containers can enable incredible application density, since you don't have the overhead of a full os image for each app. 09:05:55 Linux control groups also enable maximum utlization of the system. 09:06:03 same container can run on different versions of linux 09:06:07 - ubuntu on Fedora 09:06:12 - CentOS containers on RHEL 09:06:18 cats and dogs, living together... 09:06:32 can be very precise in resource utlization 09:06:54 what are containers not? 09:06:57 not the cure to all that ails you 09:07:51 containers are not virtualization 09:08:01 a lot of people making comparisons, but it's not the same thing. 09:08:10 kernel namespaces 09:08:21 just a wya to make a global resource appear to be unique to process. 09:08:36 can include mount, pid, uts, ipc, network and user namespaces. 09:08:44 all processes belong to one of these namespaces 09:09:02 let's drill down into what each means 09:09:15 mount - makes up processes view of the filesystem hierarchy 09:09:23 other mounts can be added for security and convenience. 09:10:13 some locations such as /proc/sys are read only as it's not completely virtualized yet 09:10:47 inside container only see filesystems that are abstracted through namespace 09:11:06 don't want to see the host unless you specifically mount a space on the host operating system 09:11:14 the /mount namespaces is how we do abstraction 09:11:21 isolate pid numbers inside the house 09:11:23 er, host 09:11:37 container thinks bash is pid 1 09:11:52 process id namespaces tell processes inside container "yes, bash is #1" 09:12:03 point is we want the container to not have awareness of what's going on in the host 09:12:30 user namespaces map UID and GID so that inside container I can have a container that appears to have root inside container but not outside / in the host. 09:12:43 can actually add ranges .. the challenge with user namespaces. 09:13:01 if I spin 50 containers, uid 0 or root access .. map to user that spawned container 09:13:12 it's isolated, ... layer sharing is hard and needs work in Linux VFS 09:14:18 IPC namespaces - what are they? Masking IPCs so table of IPCs appears to be global but is not. 09:14:44 in this case run bash, according to what's going on inside container... got zillions of them. IPC - make sure isolated what's going on iside container 09:14:53 changing gears, linux control groups. 09:14:56 sets of tasks 09:15:14 children into hierarchical .. into a control group with limits 09:15:25 if sometning happens to process in control group, even if somebody does something fancy 09:15:47 forkbomb in a control group, won't take rest of system 09:16:02 even if container is compromised, poorly-written code, misbehaved container should not impact host or other containers. 09:16:19 systemcontrol status docker 09:16:24 shows control groups 09:16:52 can navigate through /sys/fs/cgroup pseudo-directory to see processes 09:17:19 limit to 100mb of memory, and look at /proc/1/cgroup - see slices allocated to that container, all the same scope 09:17:32 if I look at memory.limit_in_bytes 09:17:51 did fork bomb, wht happens in limited amount of time that docker image dies and exits back to command prompt 09:18:00 if you look in log file, OOM gets invoked for one container. 09:18:09 kill container, rest of OS is unaffected. 09:18:32 the docker daemon itself 09:18:50 is responsible for managing the control groups, orchestrating namespaces, etc. 09:19:00 docker does run with root privs, be aware of that 09:19:11 only allow trusted users to run docker 09:19:50 if using REST API, make sure using latest versions, don't have any vulns exposed, keep systems up to date. make sure have strong auth. 09:20:14 linux kernel capabilities 09:20:24 historically root user had ability to do anything, complete access to system. 09:20:30 breaks root privs into 32 distinct controls 09:20:38 can grant only those privs required to do a job 09:20:55 can use to take away privs that root user has or grant privs to non-root user. 09:21:09 regular user can bind to privileged port, or lot of neat things you can do with linux caps. 09:21:16 catchall capability called capability sysadmin 09:25:22 #info connection dropped missed several minutes of transcription] 09:25:43 SELinux ... stored on filesystem as extended attributes 09:25:46 or in memory by kernel 09:26:13 selinux_user:selunux_role:selinux_type:mcs:mcs 09:26:22 don't use selinux user or role 09:26:32 really only care about type 09:26:42 mcs extra identifiers 09:26:49 even though identical 09:27:12 foo type on both - but difference in mcs type, SELinux says they're completely different 09:27:31 type enforcement.. policy prevent from interacting 09:27:54 netierh processes would be able to access /etc/shadow 09:28:07 all processes run in same context on system running docker 09:28:16 but on openshift, all processes run in their own context 09:28:26 selinux prevents from attacking other containers 09:29:29 even if you're running as root, selinux can block from doing malicious things - even trying to do runcon change selinux context 09:30:00 even though you're running as root, in openshift context, can't open home, can't run setenforce 0 09:30:18 let's talk about setcomp 09:30:23 syscall filtering 09:30:31 kill, errno, allow, trap, trace 09:30:47 can disable system calls like kexec_load, init_module 09:30:49 etc. 09:31:03 json file that blocks getcwd command 09:31:30 run docker run -it and read setcomp - when runs busybox... can't see directory 09:31:53 can take core system calls + blacklist and if you make part of cli to launch container you can block those system calls 09:31:56 tips and tricks 09:32:12 remember that containers at the end of the day just processes running on host. 09:32:26 process in place to update containers + update containers. 09:32:37 always run at lowest possible privilige 09:32:45 mount host as read-only 09:33:49 DON't Just download random containers from the internet 09:33:56 don't run SSH inside container 09:34:05 don't run with root privs 09:34:13 don't disable selinux 09:36:07 use selinux aware containers 09:36:18 don't roll your own containers once and never maintain them 09:36:31 need lifecycle management 09:36:40 don't run unsupported in Fedora 09:36:44 sorry 09:36:50 "don't run unsupported in production" 09:37:23 containers do leverage cool technolgy in kernel and are _relatively_ secure 09:37:34 if done right can be very, very safe 09:37:37 questions 09:37:51 ask about selinux, actually confining processes in containers? 09:38:18 yes, so - right now selinux only cares about process running on host, process on host is confied 09:38:32 run a bunch of containers ... not sure what status of selinux in containers is. 09:38:43 "not going to happen" 09:38:47 not going to namespace selinux 09:40:12 is it possible in container to modify system calls? 09:40:23 Like syscall mapping? 09:40:30 "Sure it can be done, but don't know how to do it." 09:44:15 #endmeeting