Re: [Ksummit-discuss] security-related TODO items?

[ebiederm@xmission.com (Eric W. Biederman)]

Andy Lutomirski <luto@amacapital.net> writes:

> On Tue, Jan 24, 2017 at 2:03 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> On Fri, Jan 20, 2017 at 2:38 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> Hi,
>>>>
>>>> I've already got various Kernel Self-Protection Project TODO items
>>>> collected[1] (of varying size and complexity), but recently Google's
>>>> Patch Reward Program[2] is trying to expand by helping create a bounty
>>>> program for security-related TODOs. KSPP is just one corner of
>>>> interest in the kernel, and I'd love to know if any other maintainers
>>>> have TODO items that they'd like to see get done (and Google would
>>>> potentially provide bounty money for).
>>>>
>>>> Let me know your security wish-lists, and I'll collect them all into a
>>>> single place. And if there is a better place than ksummit-discuss to
>>>> reach maintainers, I'm all ears. LKML tends to mostly just serve as a
>>>> public archive. :)
>>>>
>>>
>>> Here's another one: split up and modernize /proc.
>>>
>>> I'm imagining a whole series of changes:
>>>
>>>  - Make a sysctlfs.  You could mount it and get all the sysctls if you
>>> have global privilege.  If you only have privilege relative to some
>>> namespace, you could pass a mount option like -o scope=net to get just
>>> sysctls that belong to the mounting process' netns.  If done
>>> carefully, this should be safe for unprivileged mounting without the
>>> fs_fully_visible() checks.
>>
>> Nope.  Because the fs_fully_visible checks are there to support a root
>> policy of what can be used.  Any filesystem with content needs
>> fs_fully_visible or another way for root to say no you can't access
>> these files.
>>
>> cgroupfs gets a pass from me because we can set the number of cgroup
>> namespaces to 0, and because changing it will break userspace.
>>
>> Besides bind if you split up proc into pieces bind mounts should be
>> sufficient and you should not need to allow unprivileged users to mount
>> any of the pieces of proc.
>>
>
> Let me clarify what I meant.
>
> Currently, IIUC there are a large number of sysctls that are global to
> the system and a smaller number that only affect a single namespace.
> If you have global privilege, you could do:
>
> # mount -t sysctlfs -o scope=global none /whatever
>
> This would be disallowed entirely if you don't have global privilege.
> You could also do:
>
> # mount -t sysctlfs -o scope=net none /whatever
>
> This would *not* require global privilege or fs_fully_visible, but it
> would require ns_capable(current->nsproxy->net_ns, CAP_NET_ADMIN).
> You would get a limited syctlfs that only shows sysctls that are local
> to the network namespace of the mounter.
>
> Does that make sense?

Yes that does make sense, and that is reasonable.

Eric