[Lxc-users] dropping capabilities

[Daniel Lezcano]

On 10/04/2010 10:54 PM, richard -rw- weinberger wrote:
> Hi Daniel!
>
> On Mon, Oct 4, 2010 at 9:51 PM, Daniel Lezcano<daniel.lezcano at free.fr>  wrote:
>    
>> On 10/04/2010 06:18 PM, richard -rw- weinberger wrote:
>>      
>>> On Sun, Oct 3, 2010 at 9:01 PM, richard -rw- weinberger
>>> <richard.weinberger at gmail.com>    wrote:
>>>
>>>        
>>>> I'm using lxc to run a few virtual private servers.
>>>> What capabilities are harmful and should be dropped using "lxc.cap.drop"?
>>>>
>>>>          
>>> Is my question too trivial or too stupid? ;)
>>>
>>>        
>> hum, not trivial at all :)
>>
>> I am not sure there is a default set of capabilities to be dropped.
>> Certainly some should be dropped like CAP_SYS_MODULE but others will depend
>> on what the user expect to do with the container and what scripts will be
>> run inside the container.
>>
>> We have certainly think about the root user inside a container, is it secure
>> ? IMO, until the user namespace is not complete, it is not secure.
>>      
> I thought the user namespace is complete.
> What is missing?
>    

I am not sure, but something like "who did what", so if you are root on 
the host and you mount a filesystem, when you create an user namespace, 
will be root inside but not the same root as the host, and you won't be 
able to umount what the host's root has mounted before. I didn't 
followed the discussion about this very closely so I may be wrong.
I prefer let Serge explain what is missing, he will be much more clear 
than me :)
(cc'ed Serge).

>>> Here what i know so far:
>>>
>>> CAP_AUDIT_CONTROL:
>>>    should be dropped
>>> CAP_AUDIT_WRITE:
>>>    should be dropped
>>>        
> Update:
> To run openSUSE within lxc we need both CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE.
> I think pam uses libaudit.
>
>    
>>> CAP_CHOWN:
>>>    is ok
>>> CAP_DAC_OVERRIDE:
>>>    is ok
>>> CAP_DAC_READ_SEARCH
>>>    is ok
>>> CAP_FOWNER
>>>    is ok
>>> CAP_FSETID
>>>    is ok
>>> CAP_IPC_LOCK
>>>    is ok
>>> CAP_IPC_OWNER
>>>    is ok
>>> CAP_KILL
>>>    is ok
>>> CAP_LEASE
>>>    is ok
>>> CAP_LINUX_IMMUTABLE
>>>    is ok
>>> CAP_MAC_ADMIN
>>>    should be dropped
>>> CAP_MAC_OVERRIDE
>>>    should be dropped
>>> CAP_MKNOD
>>>    should be dropped
>>> CAP_NET_ADMIN
>>>    is ok
>>> CAP_NET_BIND_SERVICE
>>>    is ok
>>> CAP_NET_BROADCAST
>>>    is ok
>>> CAP_NET_RAW
>>>    ok?
>>>
>>>        
>> yes for the ping command for example.
>>      
> Are you sure? Within my openSUSE guest I can use ping without CAP_NET_RAW.
>    

Depending of the distro (eg. fedora), ping uses socket(,SOCK_RAW,).
This is why this command is setuid root.

>>> CAP_SETGID
>>>    is ok
>>> CAP_SETFCAP
>>>    should be dropped
>>> CAP_SETPCAP
>>>    should be dropped
>>> CAP_SETUID
>>>    is ok
>>> CAP_SYS_ADMIN
>>>    should be dropped
>>>
>>>        
>> The init process (upstart version) will need this because it mounts
>> internally /proc and /sys.
>> Some other services will need it like automount.
>>      
> IMHO CAP_SYS_ADMIN is a no-go.
> A jailed root would be able to mount the cgroup filesystem ->  game over.
>    

Yep. The cgroup can be remounted in the container but you can prevent 
the access to the directory with SMACK or SeLinux. There is a good 
document at explaining how to do that.

http://www.ibm.com/developerworks/linux/library/l-lxc-security/

>>> CAP_SYS_BOOT
>>>    should be dropped
>>>
>>>        
>> Always dropped today in the lxc-start code.
>>
>>      
>>> CAP_SYS_CHROOT
>>>    should be dropped
>>>        
> Update: sshd needs chroot().
> Is it safe to allow it?
>    

IMHO, yes.

>>> CAP_SYS_MODULE
>>>    should be dropped
>>> CAP_SYS_NICE
>>>    should be dropped
>>>
>>>        
>> The cgroup scheduler will protect the host and the other containers from an
>> abusive nice and the cpuset will prevent unauthorized affinity. So it is
>> safe to keep it I guess.
>>
>>      
>>> CAP_SYS_PACCT
>>>    should be dropped
>>> CAP_SYS_PTRACE
>>>    is ok
>>> CAP_SYS_RAWIO
>>>    should be dropped
>>> CAP_SYS_RESOURCE
>>>    should be dropped
>>> CAP_SYS_TIME
>>>    should be dropped
>>>
>>>        
>> yes and ensure /dev/rtc is read-only and protected with the cgroup devices
>> whitelist.
>>
>>      
>>> CAP_SYS_TTY_CONFIG
>>>    should be dropped
>>>
>>>        
>> I am not sure, won't getty need it ?
>>      
> You are right. We need it. :-)
>
> Thanks so far!
> //richard
>
>