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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:46 EST