lkml.org 
[lkml]   [2015]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] capabilities: Ambient capabilities
On Fri, 13 Mar 2015, Andrew G. Morgan wrote:

> > prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN);
> > system("/bin/bash");
>
> Let's call the above two lines [a] and [b]. With this patch, you are
> encouraging folk to write programs that contain a line like [a]
> already. So, yes, I am saying that you are creating an exploitable
> path in these programs that says if someone can inject
> system("/bin/bash") into these programs they can get a new (because of
> this patch) privilege escalation.

Well this is what one naively expects capabilities to give you. An ability
to avoid full superuser binaries by segmenting off capabilities. Often
there is really no other choice. If you do not provide this mode then
the system will be even less secure since people run stuff as root.

This looks to many like the design of capabilties is inherent flawed since
it does not give you what you need. You experience a go around that leads
nowhere and just wastes your time.

> In the prevailing model, this kind of privilege escalation (resulting
> from naive inheritance) is designed out. I recognize that you want to
> add it back in, but I am concerned that you are not allowing for the
> possibility that some folk might still want to still be able to
> prevent it.

The functionalty here depends on CAP_SETPCAP. That was intended as some
point to be off by default? You can have distros/kernels with that being
off.


\
 
 \ /
  Last update: 2015-03-13 17:21    [W:0.041 / U:0.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site