capable open_port() check wrong for kmem

capable open_port() check wrong for kmem

[carbonated beverage]

hi all,

	I found that I can't open /dev/kmem O_RDONLY.  The open_mem
and open_kmem calls (open_port()) in drivers/char/mem.c checks for
CAP_SYS_RAWIO.

	Is there a possibility of splitting that off into a read and
write pair, i.e. CAP_SYS_RAWIO_WRITE, CAP_SYS_RAWIO_READ?

	If not, is there a way to grant read-only access to /dev/kmem?

-- DN
Daniel

Re: capable open_port() check wrong for kmem

[David Wagner]

carbonated beverage  wrote:
>	I found that I can't open /dev/kmem O_RDONLY.  The open_mem
>and open_kmem calls (open_port()) in drivers/char/mem.c checks for
>CAP_SYS_RAWIO.
>
>	Is there a possibility of splitting that off into a read and
>write pair, i.e. CAP_SYS_RAWIO_WRITE, CAP_SYS_RAWIO_READ?

Read-only access to /dev/kmem is probably enough to get root access
(maybe you can snoop root's password, for instance).  This would make
the power of the two capabilities roughly equivalent, so if this is true,
I'm not sure I understand the point of splitting them in two this way.

Re: capable open_port() check wrong for kmem

[David Schwartz]

On 10 Dec 2002 05:45:09 GMT, David Wagner wrote:

>carbonated beverage  wrote:

>>    I found that I can't open /dev/kmem O_RDONLY.  The open_mem
>>and open_kmem calls (open_port()) in drivers/char/mem.c checks for
>>CAP_SYS_RAWIO.

>>    Is there a possibility of splitting that off into a read and
>>write pair, i.e. CAP_SYS_RAWIO_WRITE, CAP_SYS_RAWIO_READ?

>Read-only access to /dev/kmem is probably enough to get root access
>(maybe you can snoop root's password, for instance).  This would make
>the power of the two capabilities roughly equivalent, so if this is true,
>I'm not sure I understand the point of splitting them in two this way.

	Many capabilities can be leveraged into root access with sufficient 
cleverness. If this were considered a sufficient argument for merging 
capabilities, we'd have far fewer of them.

	DS

Re: capable open_port() check wrong for kmem

[carbonated beverage]

forgot to cc: linux-kernel:

Hi,

On Tue, Dec 10, 2002 at 05:45:09AM +0000, David Wagner wrote:
> Read-only access to /dev/kmem is probably enough to get root access
> (maybe you can snoop root's password, for instance).  This would make
> the power of the two capabilities roughly equivalent, so if this is true,
> I'm not sure I understand the point of splitting them in two this way.

It's rather annoying and counter-intuitive to have:

crw-r-----    1 root     kmem       1,   2 Sep  8 21:56 /dev/kmem

but to have the following code fragment give:

int fd;
	fd = open("/dev/kmem", O_RDONLY);
	if(fd == -1) {
		fprintf(stderr, "Can't open /dev/kmem: %s\n", strerror(errno));
		exit(EXIT_FAILURE);
	}

Can't open /dev/kmem: Operation not permitted

with a user in the kmem group.

Also, the utility I'm writing doesn't need write access, so why give it to
the process in the first place?

-- DN
Daniel

Re: capable open_port() check wrong for kmem

[Chris Wright]

* carbonated beverage (ramune@net-ronin.org) wrote:
> 
> It's rather annoying and counter-intuitive to have:
> 
> crw-r-----    1 root     kmem       1,   2 Sep  8 21:56 /dev/kmem
> 
> but to have the following code fragment give:
> 
> int fd;
> 	fd = open("/dev/kmem", O_RDONLY);
> 	if(fd == -1) {
> 		fprintf(stderr, "Can't open /dev/kmem: %s\n", strerror(errno));
> 		exit(EXIT_FAILURE);
> 	}
> 
> Can't open /dev/kmem: Operation not permitted
> 
> with a user in the kmem group.
> 
> Also, the utility I'm writing doesn't need write access, so why give it to
> the process in the first place?

Then open O_RDONLY (with CAP_SYS_RAWIO).  Then the utility won't have
write access.  If that's all you are worried about.

or.

If you have only one capability (CAP_SYS_RAWIO), you are not owner of
/dev/kmem, you are in group kmem, and /dev/kmem is 0640, then all you will
get is read-only access to /dev/kmem.  This does not require kernel changes.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: capable open_port() check wrong for kmem

[carbonated beverage]

On Wed, Dec 11, 2002 at 04:43:48PM -0800, Chris Wright wrote:
[snip]
> If you have only one capability (CAP_SYS_RAWIO), you are not owner of
> /dev/kmem, you are in group kmem, and /dev/kmem is 0640, then all you will
> get is read-only access to /dev/kmem.  This does not require kernel changes.

So if I want to have a generic utility that can be used by any user (and
I'm not granting CAP_SYS_RAWIO to every process), then I can:

1) make it suid root
2) drop all caps other than cap_sys_rawio

or

1) add the capability to the executable, assuming it worked...

Script started on Wed Dec 11 17:29:14 2002
UB6IB9:/home/ramune/src/hack# setcap 'cap_sys_rawio=eip' ./a.out
Failed to set capabilities on file `./a.out'
 (Function not implemented)
usage: setcap [-q] (-|<caps>) <filename> [ ... (-|<capsN>) <filenameN> ]
UB6IB9:/home/ramune/src/hack# mount
/dev/hda1 on / type ext3 (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
UB6IB9:/home/ramune/src/hack# uname -a
Linux UB6IB9 2.4.20 #1 Sat Nov 30 20:51:01 PST 2002 i586 unknown
UB6IB9:/home/ramune/src/hack#
Script done on Wed Dec 11 17:29:31 2002

So, what am I missing?

I just have to make it suid root if I wanna use it on 2.4.x?  Or is there
a problem with my setup causing setcap to fail?

-- DN
Daniel

Re: capable open_port() check wrong for kmem

[Chris Wright]

* carbonated beverage (ramune@net-ronin.org) wrote:
> 
> So if I want to have a generic utility that can be used by any user (and
> I'm not granting CAP_SYS_RAWIO to every process), then I can:
> 
> 1) make it suid root
> 2) drop all caps other than cap_sys_rawio
> 
> or
> 
> 1) add the capability to the executable, assuming it worked...

this is not supported without kernel patches.  in general you have to
start with full capabilities and shed the ones you don't need.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: capable open_port() check wrong for kmem

[Olaf Dietsche]

carbonated beverage <ramune@net-ronin.org> writes:

> 	I found that I can't open /dev/kmem O_RDONLY.  The open_mem
> and open_kmem calls (open_port()) in drivers/char/mem.c checks for
> CAP_SYS_RAWIO.
>
> 	Is there a possibility of splitting that off into a read and
> write pair, i.e. CAP_SYS_RAWIO_WRITE, CAP_SYS_RAWIO_READ?
>
> 	If not, is there a way to grant read-only access to /dev/kmem?

You may want to look at this thread:
<http://groups.google.com/groups?threadm=87smza1p7f.fsf%40goat.bogus.local>

Regards, Olaf.

Re: capable open_port() check wrong for kmem

[carbonated beverage]

On Tue, Dec 10, 2002 at 12:33:04PM +0100, Olaf Dietsche wrote:
[snip]
> You may want to look at this thread:
> <http://groups.google.com/groups?threadm=87smza1p7f.fsf%40goat.bogus.local>

Hmm.

Okay, which approach is generally accpetible for inclusion into the kernel?
1) Nuke CAP_SYS_RAWIO check.  If the permissions on /dev/kmem is wrong,
tough.  It shouldn't be root:root 0666 in the first place anyways.
2) Add CAP_SYS_KMEM for read-only access, check for CAP_SYS_RAWIO for
the write case.
3) Special case /dev/kmem in open_port.

or:

4) Even if an application doesn't need write access to /dev/kmem, require
it to open /dev/kmem O_RDWR, as  it makes life easier for many people,
especially when modifying the kernel at run-time to hijack sysca... um, do
creative updates. :)

I'd prefer #1 or #2, but the discussion seems to have ended during the last
time the issue was brought up.

-- DN
Daniel