Re: root and capabilities list

2014-10-14 Thread ds


On 15.10.2014 04:54, Colin Watson wrote:


  Martin's right - CAP_SYS_MODULE is functionally equivalent to root.

I see.
Anyway, there is another part, reading the msr and cpuid. For that, it 
seems to be really beneficial, to make it available to everyone. So the 
process which needs it, can only live with limited CAP_SYS_RAWIO powers. 
It seem to me, that the root rights are there only because the 
capability system was introduced only a couple of years ago, and the msr 
and cpuid part was not yet changed with capabilities in mind.
As i said, i am new to linux, so not sure how it all works, and where to 
discuss the whole thing.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: root and capabilities list

2014-10-14 Thread Colin Watson
On Tue, Oct 14, 2014 at 10:44:26PM +0400, ds wrote:
> On 14.10.2014 22:37, Martin Pitt wrote:
> >Note that at least CAP_SYS_MODULE is equivalent to root (as you can
> >load any local .ko which can then provide you with a backdoor into
> >the kernel),
> 
> I guess you have to put the .ko file at a protected place of
> filesystem for it to get loaded.

No, the init_module(2) syscall takes the module image as a buffer in
memory, and you can use that syscall if you have CAP_SYS_MODULE.

> And maybe it would even require recompiling kernel with your .ko in
> mind.

It is very unlikely that one would not be able to find some way to
escalate to root given the ability to construct an arbitrary kernel
module, without needing to recompile the kernel.  In general, once an
attacker can load kernel modules, you've already lost.  Martin's right -
CAP_SYS_MODULE is functionally equivalent to root.

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: root and capabilities list

2014-10-14 Thread ds


On 14.10.2014 22:37, Martin Pitt wrote:
Ah, how does that work? I'm not aware of an ELF/kernel feature which 
allows doing that, this sounds interesting? 

https://www.insecure.ws/2013/12/17/lesser-known-tool-of-the-day-getcap-setcap-and-file-capabilities/
Note that at least CAP_SYS_MODULE is equivalent to root (as you can 
load any local .ko which can then provide you with a backdoor into the 
kernel),
I guess you have to put the .ko file at a protected place of filesystem 
for it to get loaded. And maybe it would even require recompiling kernel 
with your .ko in mind. I am not sure how it works. I only use ubuntu for 
a month now.


If open and read on them is additionally protected by CAP_SYS_RAWIO, 
then world-readability should not hurt indeed (note that I haven't 
verified this). Martin 

Trust me. Tried already.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: root and capabilities list

2014-10-14 Thread Martin Pitt
ds [2014-10-14 22:31 +0400]:
> Yes it is. the capability is set on exe file by the installer.

Ah, how does that work? I'm not aware of an ELF/kernel feature which
allows doing that, this sounds interesting?

> The exe itself should never acquire root ideally. Only has the
> limited subset of root powers CAP_SYS_RAWIO and CAP_SYS_MODULE

Note that at least CAP_SYS_MODULE is equivalent to root (as you can
load any local .ko which can then provide you with a backdoor into the
kernel), so from a security POV this doesn't help much. Of course
you'd drop both root privs and CAP_SYS_MODULE right after program
initialisation when you don't need them any more.

The other workaround would be if your project ships and udev rule
which makes the msr devices world readable. We don't currently have
any explicit rule for msr as far as I can see, so they are just using
the kernel defaults in devtmpfs. If open and read on them is
additionally protected by CAP_SYS_RAWIO, then world-readability should
not hurt indeed (note that I haven't verified this).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: root and capabilities list

2014-10-14 Thread ds

On 14.10.2014 22:23, Martin Pitt wrote:
You also need root to initially get those CAP_*, so this is not a real 
limitation. 
Yes it is. the capability is set on exe file by the installer. The exe 
itself should never acquire root ideally. Only has the limited subset of 
root powers CAP_SYS_RAWIO and CAP_SYS_MODULE






--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: root and capabilities list

2014-10-14 Thread Martin Pitt
Hello ds,

ds [2014-10-14 21:44 +0400]:
> I'm trying to write a widget, which reports intel CPUs power
> consumption. For that, the widget needs access to /dev/cpu/.../msr,
> as well as ability to load kernel modules cpuid and msr.
> I can set CAP_SYS_RAWIO capability to get the access, but the
> problem is that /dev/cpu/.../msr & cpuid files can only be read
> and written by root.

You also need root to initially get those CAP_*, so this is not a real
limitation. So this should work:

  - start as root (the widget itself or preferably a small helper
which reads the data from /dev/ and reports it on stdout or D-BUS
or so)
  - open /dev/cpu/*
  - (if necessary) modprobe stuff
  - prctl(PR_SET_KEEPCAPS)
  - setgid()/setuid() to drop privileges
  - setpcap() to only keep CAP_SYS_RAWIO

Then your process will run as user with only CAP_SYS_RAWIO, and has
open fds to /dev/cpu/* which you can continue to use.

FWIW, I find it pretty pointless that you need a capability to read
from an open fd -- it should suffice to have the capability to open()
the device. The kernel had had the same mis-design with /proc/kmsg for
years which prevented effective privilege dropping in klogd.

Thus ideally you should start as root, open /dev/*, then suid() and
run as normal user without extra privs and can do without the
capability dance.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


root and capabilities list

2014-10-14 Thread ds

  
  
Greetings!

I'm trying to write a widget, which reports intel CPUs power
consumption. For that, the widget needs access to /dev/cpu/.../msr,
as well as ability to load kernel modules cpuid and msr.
I can set CAP_SYS_RAWIO capability to get the access, but the
problem is that /dev/cpu/.../msr & cpuid files can only be read
and written by root. Which i find stupid, since the simple widget
still needs to acquire the whole root just to report power usage.
And that is exactly what "the capability" feature was trying to
prevent. It would have been more sane, if those files were
accessible for rw by anyone, since access to them now requires the
CAP_SYS_RAWIO capability anyway. In this case, the widget won't need
the whole root, but just the capability. 
Same applies to CAP_SYS_MODULE for loading/removing kernel modules.
Generally speaking, I think the root access policies should be
reconsidered with the introduction of the capability system.

  


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss