[Ksummit-discuss] security-related TODO items?

Andy Lutomirski luto at amacapital.net
Tue Mar 7 16:25:39 UTC 2017


On Tue, Mar 7, 2017 at 8:12 AM, Djalal Harouni <tixxdz at gmail.com> wrote:
>
>
> On Tue, Jan 24, 2017 at 3:38 AM, Andy Lutomirski <luto at amacapital.net>
> wrote:
>> On Fri, Jan 20, 2017 at 2:38 PM, Kees Cook <keescook at 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.
>>
>>  - Teach procfs to understand mount options for real (per-superblock).
>> Shouldn't be that hard.
>
> I spent some time investigating this to advance in this option in order to
> improve procfs hidepid and replace that per task hidepid solution... the
> result: this proposition will break userspace in a real bad way...
>
> Since procfs is a virtual fs we always generate a new 'st_dev' device ID
> that's used to get the major and minor IDs for that device.

If necessary, we could change that for procfs and have the same st_dev
for mounts in the same pidns.


More information about the Ksummit-discuss mailing list