2.5.42: remove capable(CAP_SYS_RAWIO) check from open_kmem

RFC PATCH Olaf Dietsche 3 participants 5 messages Oct 13, 2002 – Oct 17, 2002 2 messages not in the archive

lore

Share & tools

lore

Olaf Dietsche

author

2002-10-13 16:40 UTC #3 lore raw

In reply to a message not in the archive

Quoted 10 lines · Manfred Spraul

Quoted 9 lines · Olaf Dietsche
Quoted 6 lines · Manfred Spraul
Quoted 5 lines
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.

Quoted 7 lines

Quoted 6 lines
Quoted 1 line
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 :-)

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 10 lines

Quoted 7 lines
Quoted 2 lines
, 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.

Olaf Dietsche

author

2002-10-13 16:42 UTC #1 lore raw

In reply to a message not in the archive

Quoted 6 lines · Manfred Spraul

Quoted 5 lines
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.

Quoted 2 lines

, 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?

Regards, Olaf.

Manfred Spraul

2002-10-13 16:58 UTC #4 lore raw

In reply to Olaf Dietsche

Quoted 5 lines · Olaf Dietsche

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.

What about writing a small wrapper application that drops all priveleges except CAP_RAWIO, switches to user to the user you want, then execs the target application that needs to access /dev/kmem?

Or store the capabilities in the filesystem, but I don't know which filesystem supports that.

--
Manfred

Olaf Dietsche

author

2002-10-13 22:00 UTC #5 lore raw

Quoted 8 lines · Manfred Spraul

Quoted 4 lines · Olaf Dietsche
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.
What about writing a small wrapper application that drops all priveleges except CAP_RAWIO, switches to user to the user you want, then execs the target application that needs to access /dev/kmem?

I just tried this, but I didn't succeed. :-(

Quoted 2 lines

Or store the capabilities in the filesystem, but I don't know which filesystem supports that.

There's none so far.

Regards, Olaf.

Andreas Steinmetz

2002-10-17 12:03 UTC #6 lore raw

Quoted 5 lines

Quoted 3 lines
What about writing a small wrapper application that drops all priveleges except CAP_RAWIO, switches to user to the user you want, then execs the target application that needs to access /dev/kmem?

Quoted 9 lines

I just tried this, but I didn't succeed. :-(
Quoted 2 lines
Or store the capabilities in the filesystem, but I don't know which filesystem supports that.
There's none so far.

Not exactly. Well, not really a filesystem. But there's already security use of this feature you want to remove. Think LSM. Look at e.g. LIDS. Im using this additional protection already under 2.4.x to prevent uid 0 processes to access /dev/mem and /dev/kmem where not explicitely granted. Please, _don't_ remove the capability check because you don't see any use for it as there _is_ already use for it.

Signature · 2 lines

Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH