Re: [PATCH][RFC] 2.5.42: remove capable(CAP_SYS_RAWIO) check from open_kmem

[Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de>]

Manfred Spraul <manfred@colorfullife.com> writes:

> Olaf Dietsche wrote:
>  > Manfred Spraul <manfred@colorfullife.com> writes:
>  >
>  >
>  >>>In drivers/char/mem.c there's open_port(), which is used as open_mem()
>  >>>and open_kmem() as well. I don't see the benefit of this, since
>  >>>/dev/mem and /dev/kmem are already protected by filesystem
>  >>>permissions.
>  >>>
>  >>
>  >>capabilities can be stricter than filesystem permissions
>  >
>  >
>  > Which means, it prevents me from giving access to /dev/kmem to an
>  > otherwise unprivileged process.
>  >
> Do you know what access to /dev/kmem means?

Which is not the point. Just assume for a moment, I know what I'm
doing :-)

> A process that can read /dev/kmem can read /etc/shadow and probaly all
> other files he can force into memory.
>
> A process that can write to /dev/kmem can give himself ultimate
> capabilities by modifying it's own uid/capability set.

Now, I have to run this process as root, regardless of filesystem
permissions. So, if I trust this particular process with full
privileges now, there's no problem in reducing its power a little bit.

> Have you tried to disable the capabilities? I think there is a kernel
> option that disables them.

I don't want to disable capabilities. I want to get rid of this
particular use.

>>>, and the call
>>>is needed to update the PF_SUPERPRIV process flag.
>> What exactly is PF_SUPERPRIV good for? I see no real use in the
>> source. There is exactly one test for this flag (kernel/acct.c:336),
>> then sets another flag (ASU), which in turn is used nowhere else.
>> So, I think we could get rid of this flag as well. Comments?
>>
>
> Part of BSD process accounting - you have just broken backward
> compatibility with user space.

Ok, thanks for this hint.

Regards, Olaf.