[Lxc-users] dropping capabilities

[richard -rw- weinberger]

On Tue, Oct 5, 2010 at 11:23 AM, Daniel Lezcano <daniel.lezcano at free.fr> wrote:
> 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/

Yeah, but there are more problems. For example on my test system /lxc
is a separate filesystem. With CAP_SYS_ADMIN a evil guy could do "ln
-s /proc/mounts /etc/mtab ; mount / -o remount,ro" and all other lxc
instances are unusable...

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



-- 
Cheers,
//richard