removing debugfs

[Stefan Bader]

On 01/25/2011 03:31 AM, Tim Gardner wrote:
> On 01/24/2011 07:19 PM, Kees Cook wrote:
>> Hi,
>>
>> On Tue, Jan 25, 2011 at 11:48:13AM +1000, Ben Hutchings wrote:
>>> On Mon, 2011-01-24 at 14:13 -0800, Kees Cook wrote:
>>>> I have yet another unpopular request: I want to remove debugfs completely
>>>> from the built kernels. Upstream continues to put dangerous things in it,
>>>> and I want to avoid the problems completely.
>>> [...]
>>>
>>> I agree that it should not be mounted by default, or relied on by any
>>> user-space packages.  However, I don't see the need to disable it
>>> altogether.
>>
>> My specific issue with it is the acpi_method interface, which nullifies the
>> /dev/mem and /dev/kmem restrictions (i.e. a root user can once again
>> arbitrarily write to memory). The defenses for kernel rootkits require that
>> the root user not have any way to write to kernel memory (nor load arbitrary
>> modules).
>>
>> For example, without debugfs and barring unknown vulnerabilities,
>> if a system owner chooses at boot time to echo 1 into
>> /proc/sys/kernel/modules_disabled, there isn't a way to modify the
>> running kernel. Unfortunately, with acpi_method, this is no longer true.
>>
>> I'd like to remove debugfs completely so it cannot just be trivially
>> mounted and abused, and to avoid potential future problems.
>>
>> As mentioned, though, the minimal compromise will be to just flat remove
>> acpi_method, as it is a real and present danger as opposed to some set of
>> future unknown dangers. :)
>>
>> -Kees
>>
> 
> Is this sufficient?
> 
> rtg
> 
Just to add my 1cent: I also would rather prefer to only disable the acpi part
and not the whole of debugfs. Not to mount it by default ok, but there is just
too much useful things in there to track gpu hangs or trace usb traffic that
helps a lot to debug issues and to have to provide a debug enabled kernel just
for that seems more waste than the security risk I see from having it there.
(the paranoid can delete or blacklist the module).

-Stefan