I just want to run an exectable with limited capabilities and assumed
the following approach would work fine:
1) fork process
2) in child
2.1 set current capabilities (eip) using cap_set_proc
2.2 execve the executable.
But it frigging does not work! Just before the execve, the result of
cap_to_text is
= cap_net_bind_service+eip
but, in the execve executable, the result is suddenly
= cap_net_bind_service+i
Why does the execve clear the effective and permitted capabities,
against my clear instructions? (I also have the prctl KEEP_CAPS set,
though in this case it should be irrelevant).
- The kernel is from ubuntu distro, 2.6.24.
- the executable *does* *not* have any setuid/setgid bits
- the upcoming file capabities will not be any help, because I will
need to start the same executable with different capabilities
depending on context.
If this is not a bug in kernel, it is a misdesign, which makes the
obvious use of cap_set_proc rather useless...
--
Markku Savela
On Wed 2008-08-27 12:31:10, Markku Savela wrote:
> I just want to run an exectable with limited capabilities and assumed
> the following approach would work fine:
>
> 1) fork process
> 2) in child
>
> 2.1 set current capabilities (eip) using cap_set_proc
> 2.2 execve the executable.
>
> But it frigging does not work! Just before the execve, the result of
> cap_to_text is
>
> = cap_net_bind_service+eip
>
> but, in the execve executable, the result is suddenly
>
> = cap_net_bind_service+i
>
> Why does the execve clear the effective and permitted capabities,
> against my clear instructions? (I also have the prctl KEEP_CAPS set,
> though in this case it should be irrelevant).
>
> - The kernel is from ubuntu distro, 2.6.24.
>
> - the executable *does* *not* have any setuid/setgid bits
>
> - the upcoming file capabities will not be any help, because I will
> need to start the same executable with different capabilities
> depending on context.
Yes, you need upcoming filesystem capabilities. Binary may not
inherit capabilities unless filesystem flags permit that.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> From: Pavel Machek <[email protected]>
> Yes, you need upcoming filesystem capabilities. Binary may not
> inherit capabilities unless filesystem flags permit that.
I think this is wrong. Normal executables inherit uid/gid and
supplementary groups by default. Why should capabilities be any
different?
IMHO, even with file system capabilities, the default should be
inherit, if nothing else is specified.
On Thu, Aug 28, 2008 at 05:45:34PM +0300, Markku Savela wrote:
>
> > From: Pavel Machek <[email protected]>
>
> > Yes, you need upcoming filesystem capabilities. Binary may not
> > inherit capabilities unless filesystem flags permit that.
>
> I think this is wrong. Normal executables inherit uid/gid and
> supplementary groups by default. Why should capabilities be any
> different?
Well, because that's not the what the POSIX draft specification (and
the rest of the Unix industry who were striving to meet the US
Department of Defense's "B2 by '92" initiative) ended up implementing.
The reason for that was to avoid bugs where a program that wasn't
expecting to be setuid (or just written by a stupid progammer) exec's
some program which wasn't expecting to have root privileges then bad
things happen. The classic example of this was running the mail
program, which was setuid or setgid to the mail user/group, and then
typing "!/bin/sh" which would exec a shell running with those
privileges (because the mail program didn't know to drop its
privileges).
So in the capabilities model, the capabilities do *not* inherit unless
the a particular file explicitly states that it should inherit the
capabilities. It's the principle of least privilege taken to its
logical conclusion.
- Ted
On Thu, 2008-08-28 at 13:48 -0400, Theodore Tso wrote:
> On Thu, Aug 28, 2008 at 05:45:34PM +0300, Markku Savela wrote:
> >
> > > From: Pavel Machek <[email protected]>
> >
> > > Yes, you need upcoming filesystem capabilities. Binary may not
> > > inherit capabilities unless filesystem flags permit that.
> >
> > I think this is wrong. Normal executables inherit uid/gid and
> > supplementary groups by default. Why should capabilities be any
> > different?
>
> Well, because that's not the what the POSIX draft specification (and
> the rest of the Unix industry who were striving to meet the US
> Department of Defense's "B2 by '92" initiative) ended up implementing.
Minor nit. It was actually C2(Controlled Access Protection) by '92 which
is mainly just DAC protections as opposed to B2(Structured Protection)
which also included MAC policies and Sensitivity labels in addition to
DAC protections.
Dave
David P. Quigley wrote:
> On Thu, 2008-08-28 at 13:48 -0400, Theodore Tso wrote:
>
>> On Thu, Aug 28, 2008 at 05:45:34PM +0300, Markku Savela wrote:
>>
>>>> From: Pavel Machek <[email protected]>
>>>>
>>>> Yes, you need upcoming filesystem capabilities. Binary may not
>>>> inherit capabilities unless filesystem flags permit that.
>>>>
>>> I think this is wrong. Normal executables inherit uid/gid and
>>> supplementary groups by default. Why should capabilities be any
>>> different?
>>>
>> Well, because that's not the what the POSIX draft specification (and
>> the rest of the Unix industry who were striving to meet the US
>> Department of Defense's "B2 by '92" initiative) ended up implementing.
>>
>
> Minor nit. It was actually C2(Controlled Access Protection) by '92 which
> is mainly just DAC protections as opposed to B2(Structured Protection)
> which also included MAC policies and Sensitivity labels in addition to
> DAC protections
But the fun part was that the evaluation requirements for B1,
which fell in between C2 and B2 (the order from least secure to
most was D, C1, C2, B1, B2, B3, A1, and "Beyond A1") where so
close to those for C2 that everyone implemented B1, which did
include MAC policy in the form of Bell and LaPadula sensitivity.
The privilege model (now called capabilities, and you have to buy
me a beer to get the whole story) does not actually come in the
requirements until B3, although some people will argue that it
was intended they be included at B2. Even though no one even tried
a B3 and no one succeeded at B2 everyone did capabilities based
on one of the drafts or another.
Anyone who thinks that the capability scheme is wrong headed is
encouraged to read the P1003.1e/2c (withdrawn) DRAFT. It's on
the web in several places. You may end up still thinking it's
wrong, but at least you will have seen how the arguments got
hashed out.
And we're still not talking about the Jackson Hole meeting.
> From: Theodore Tso <[email protected]>
> The reason for that was to avoid bugs where a program that wasn't
> expecting to be setuid (or just written by a stupid progammer) exec's
> some program which wasn't expecting to have root privileges then bad
> things happen. The classic example of this was running the mail
> program, which was setuid or setgid to the mail user/group, and then
> typing "!/bin/sh" which would exec a shell running with those
> privileges (because the mail program didn't know to drop its
> privileges).
Considering the current case, without the file capabilites, I note
- if the caller of /bin/sh is ROOT, the capabities are inherited. Thus
my request has no relevance in that case.
- if the caller does first setuid to non-root, the capabilities are
cleared, unless KEEP_CAPS is explicitly set. Thus, my requested
change would not cause problems with your buggy mail program.
- if the caller goes through all the trouble of setting KEEP_CAPS and
changing to non-root, I would expect it to be sensible that the
caller also intends the execve code to inherit capabilities.
As an experiment and example, I made a small patch to Ubuntu 2.6.24
kernel, to make it work like I think it should: if KEEP_CAPS is set,
they are inherited (see at end).
I'm ok with the current kernel code, which seems to clear the
KEEP_CAPS on execve. Thus, each executable must again re-enable it, if
it needs capabilities inherited further...
> So in the capabilities model, the capabilities do *not* inherit unless
> the a particular file explicitly states that it should inherit the
> capabilities. It's the principle of least privilege taken to its
> logical conclusion.
I'm looking at network oriented devices, where executables or
interpreted content from network sources is executed by helper
applications or directly as executables. Depending on the source of
the "code", the helper application or the downloaded exectuable may be
allowed to run with different permissions (capabilities, uid/gid
etc). [For example, look at android security model with manifests of
requested and declared permissions, but applied to everything
downloaded or installed].
File capabilities (nor selinux) won't work, because the "helper
applications" need to be executed with different capabilities and
permissions, depending on the "manifests" of the downloaded
"code". Obviously, serious permissions are granted only to properly
verified "code" (signed).
[Any ideas how selinux would help to enforce a permission which is
dynamically defined by installing application?]
I'm using "code" in quotes, because in my mind, it can include HTML,
word documents, spreadsheets, images. Data formats are getting so
complex, that they start to look more like interpreted code, than
plain passive data.
File capabilities (and setuid/setgid bits, selinux attributes) have
another problem: they only work properly on internal disk. No sane
person would allow them to be effective from removable media or NFS.
-------------------
This only handles the case where file capabilities are not enabled. If
enabled, I would need to remove the bprm_clear_caps call from the
branch that gets executed when the file does not have any special
capabilities defined.
-------------------
--- fs/exec.c.orig 2008-08-21 00:51:46.000000000 +0300
+++ fs/exec.c 2008-08-28 11:18:13.000000000 +0300
@@ -1072,6 +1072,12 @@
bprm->e_uid = current->euid;
bprm->e_gid = current->egid;
+ if (current->keep_capabilities) {
+ bprm->cap_inheritable = current->cap_inheritable;
+ bprm->cap_permitted = current->cap_permitted;
+ bprm->cap_effective = 1;
+ }
+
if(!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
/* Set-uid? */
if (mode & S_ISUID) {
--- security/commoncap.c.orig 2008-08-21 00:51:47.000000000 +0300
+++ security/commoncap.c 2008-08-28 16:20:34.000000000 +0300
@@ -282,7 +282,7 @@
static inline int get_file_caps(struct linux_binprm *bprm)
{
- bprm_clear_caps(bprm);
+ /*bprm_clear_caps(bprm); */
return 0;
}
#endif
On Fri, 29 Aug 2008, Markku Savela wrote:
> File capabilities (nor selinux) won't work, because the "helper
> applications" need to be executed with different capabilities and
> permissions, depending on the "manifests" of the downloaded
> "code". Obviously, serious permissions are granted only to properly
> verified "code" (signed).
>
> [Any ideas how selinux would help to enforce a permission which is
> dynamically defined by installing application?]
You could implement a specialized userpsace application launcher, which
parses the manifest, determines a security context for the application,
performs any requiste object labeling, then launches the application it in
that context. The kernel policy could enforce which particular contexts
the launcher was authorized to use, and which applications could be
launched in this way, then confine the launched applications.
>
> I'm using "code" in quotes, because in my mind, it can include HTML,
> word documents, spreadsheets, images. Data formats are getting so
> complex, that they start to look more like interpreted code, than plain
> passive data.
>
> File capabilities (and setuid/setgid bits, selinux attributes) have
> another problem: they only work properly on internal disk. No sane
> person would allow them to be effective from removable media or NFS.
There is a project underway to extend SELinux (and MAC labeling in
general) over NFS: http://selinuxproject.org/page/Labeled_NFS
- James
--
James Morris
<[email protected]>
On Fri, Aug 29, 2008 at 01:18:38PM +0300, Markku Savela wrote:
> Considering the current case, without the file capabilites, I note
>
> - if the caller of /bin/sh is ROOT, the capabities are inherited. Thus
> my request has no relevance in that case.
In the full capabilities model (which we can't have until file
capabilities get added), having a user id of 0 has no meaning. The
whole concept of "root" goes away. Like SELinux, turning it on
without making sure programs are ready for it will break a lot of
things.
> - if the caller does first setuid to non-root, the capabilities are
> cleared, unless KEEP_CAPS is explicitly set. Thus, my requested
> change would not cause problems with your buggy mail program.
>
> - if the caller goes through all the trouble of setting KEEP_CAPS and
> changing to non-root, I would expect it to be sensible that the
> caller also intends the execve code to inherit capabilities.
What you are suggesting is not insane. But then again, the setuid
root (and allow a process to inherit all privileges) model wasn't
insane either. The full capabilities model, however, is striving to
far more stringent than either the traditional root-oriented model or
your concept of allowing the program to decide (on its own) whether it
a downstream exec should inherit its privileges. And what it is
trying to do is this:
It is very reasonable to suggest that a system administrator, or a
site security officer, be able to audit a system and know what
programs can run with any kind of elevated privileges (and I still
prefer the term "privileges" to "capabilities"; one of these days I
will need to buy Casey a beer). But if you allow unbridled
inheritance, you Just Don't Know who could run as root. If you make
it based on whether KEEP_CAPS is set, it still becomes impossible for
a system administrator to audit all of the binaries on the system ---
for the simple reason that the system administrator may not have
access to the sources, and even if she did, how would she know whether
the sources precisely matched up to the binaries, in every single
case? And even if she did know how would she know what program or
programs a particular privileged program could exec? It's just not
possible.
The solution in the capabilities model is that each executable has a
capability bitmask which indicates which privileges it is allowed to
inherit --- and the default is no privileges whatsoever. This means
that just as today, a system administrator or site security officer
can scan for setuid root programs, in the capabilities world, it is
possible to determine exactly which binaries could ever run with
elevated privileges, ever. And in order to do it, the permission to
do this needs to be in the filesystem, and not in some magic KEEP_CAPS
flag.
The KEEP_CAPS flag is simply a transition mechanism, before we have
full filesystem cpabilties and can implement the full capabilities
model, because it controls what happens when you make the move from
root to non-root. In the capabilties world, "root" simply has no
meaning, so KEEP_CAPS would become vestigal once full capabilities is
enabled.
Your proposed change of overloading KEEP_CAPS to also mean that a
program can inherit has the downside that programs that try to take
advantage of this will break on a system with file capabilties
enabled. Perhaps a better way of doing what you want would be to
replace the non-file capabilities version of get_file_caps with
something like this:
static inline int get_file_caps(struct linux_binprm *bprm)
{
bprm->cap_post_execu_permitted = current->cap_inheritable;
bprm->cap_effective = true;
return 0;
}
Now if you want to pass some subset of your capabilities to a child
process, you have to set your processes's inheritable bitmask with the
capabilities you want passed down. This is better than KEEP_CAPS,
since KEEP_CAPS is all or nothing, and this allows you to be selective
(and explicit) about which capabilties should be inherited. It is
also forwards compatibile with the full capabilities model, since the
(simplified) inheritance model is:
pP' = fP | (pI & fI)
where:
pP' is the new process's permitted capset
fP is the executable's permitted capset (think of this as
"setuid" bits)
fI is the executable's inheritable capset
pI is the process's inheritable capset
Previously, in effect without file capabilities, fP and fI were set to
0, which disabled capability inheritiance. This change effectively
makes fI ~0. This means that the process can decide to pass
capabilities to a downstream exec, and we assume (in the absence of
file capabilities) that the executable always has the permission to
receive these capabilities.
If you do then migrate to the full capability model, the system
adminsitrator will have to set the fI bits appropriate for all
processes that need to be able to receive capabilities, but your
existing programs will already be doing mostly the right thing.
> File capabilities (nor selinux) won't work, because the "helper
> applications" need to be executed with different capabilities and
> permissions, depending on the "manifests" of the downloaded
> "code". Obviously, serious permissions are granted only to properly
> verified "code" (signed).
Downloaded applications (or data which implies starting some helper
application) gets very hard, because even if the code is "signed",
there is the question of whether you trust the signer? And maybe you
trust the signer in some contexts, but not in others. Furthermore,
how you probably want to restrict such downloaded applications (or
data which instructs a helper application how to behave) is probably
far more than just subsets of superuser privileges. Even if the the
process is running without any elevated privileges, you may not want
it deleting all of your home directory, or sending a copy of all of
your mail folders over the network to an attacker. So that implies
needing to run the application in some kind of captive sandbox. And
at this point, we end up going *far* beyond the scope of the
capabilities discussion.
> File capabilities (and setuid/setgid bits, selinux attributes) have
> another problem: they only work properly on internal disk. No sane
> person would allow them to be effective from removable media or NFS.
Absolutely, and just as we have to mount non-trusted filesystems with
nosuid, the same has to apply for capabilities. But while this is a
"reduced to a previously unsolved problem", I don't think it's a major
problem. We've all learned to live with the fact that if you want a
secure system, all of your programs that need to run with elevated
privileges be located on trusted filesystems, and in practice, this
isn't a major limitation. If you want to keep the system easily
evaluated for security, you have to do this anyway.
- Ted
On Thu, 2008-08-28 at 21:47 -0700, Casey Schaufler wrote:
> David P. Quigley wrote:
> > On Thu, 2008-08-28 at 13:48 -0400, Theodore Tso wrote:
> >
> >> On Thu, Aug 28, 2008 at 05:45:34PM +0300, Markku Savela wrote:
> >>
> >>>> From: Pavel Machek <[email protected]>
> >>>>
> >>>> Yes, you need upcoming filesystem capabilities. Binary may not
> >>>> inherit capabilities unless filesystem flags permit that.
> >>>>
> >>> I think this is wrong. Normal executables inherit uid/gid and
> >>> supplementary groups by default. Why should capabilities be any
> >>> different?
> >>>
> >> Well, because that's not the what the POSIX draft specification (and
> >> the rest of the Unix industry who were striving to meet the US
> >> Department of Defense's "B2 by '92" initiative) ended up implementing.
> >>
> >
> > Minor nit. It was actually C2(Controlled Access Protection) by '92 which
> > is mainly just DAC protections as opposed to B2(Structured Protection)
> > which also included MAC policies and Sensitivity labels in addition to
> > DAC protections
>
> But the fun part was that the evaluation requirements for B1,
> which fell in between C2 and B2 (the order from least secure to
> most was D, C1, C2, B1, B2, B3, A1, and "Beyond A1") where so
> close to those for C2 that everyone implemented B1, which did
> include MAC policy in the form of Bell and LaPadula sensitivity.
> The privilege model (now called capabilities, and you have to buy
> me a beer to get the whole story) does not actually come in the
> requirements until B3, although some people will argue that it
> was intended they be included at B2. Even though no one even tried
> a B3 and no one succeeded at B2 everyone did capabilities based
> on one of the drafts or another.
>
> Anyone who thinks that the capability scheme is wrong headed is
> encouraged to read the P1003.1e/2c (withdrawn) DRAFT. It's on
> the web in several places. You may end up still thinking it's
> wrong, but at least you will have seen how the arguments got
> hashed out.
>
> And we're still not talking about the Jackson Hole meeting.
>
And one wonders why these certs aren't in use anymore ;)
Dave
Quoting Pavel Machek ([email protected]):
> On Wed 2008-08-27 12:31:10, Markku Savela wrote:
> > I just want to run an exectable with limited capabilities and assumed
> > the following approach would work fine:
> >
> > 1) fork process
> > 2) in child
> >
> > 2.1 set current capabilities (eip) using cap_set_proc
> > 2.2 execve the executable.
> >
> > But it frigging does not work! Just before the execve, the result of
> > cap_to_text is
> >
> > = cap_net_bind_service+eip
> >
> > but, in the execve executable, the result is suddenly
> >
> > = cap_net_bind_service+i
> >
> > Why does the execve clear the effective and permitted capabities,
> > against my clear instructions? (I also have the prctl KEEP_CAPS set,
KEEP_CAPS prevents capability set clearing at setuid, not at exec.
> > though in this case it should be irrelevant).
> >
> > - The kernel is from ubuntu distro, 2.6.24.
> >
> > - the executable *does* *not* have any setuid/setgid bits
> >
> > - the upcoming file capabities will not be any help, because I will
> > need to start the same executable with different capabilities
> > depending on context.
They will help. The context is pI. When a file is executed, the task's
new permitted set is calculated as:
pP' = (fI&pI) | (fP & X)
So you can give /bin/foo the file capabilities:
fI=cap1,cap2,cap3
Then task 1 runs with pI=cap1, so when it executes /bin/foo it will get
pP' = cap1
Task 2 runs with pI=cap2,cap3,cap4 so when it executes /bin/foo it will
get
pP' = cap2,cap3
> Yes, you need upcoming filesystem capabilities. Binary may not
> inherit capabilities unless filesystem flags permit that.
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Quoting Markku Savela ([email protected]):
> > From: Theodore Tso <[email protected]>
>
> > The reason for that was to avoid bugs where a program that wasn't
> > expecting to be setuid (or just written by a stupid progammer) exec's
> > some program which wasn't expecting to have root privileges then bad
> > things happen. The classic example of this was running the mail
> > program, which was setuid or setgid to the mail user/group, and then
> > typing "!/bin/sh" which would exec a shell running with those
> > privileges (because the mail program didn't know to drop its
> > privileges).
>
> Considering the current case, without the file capabilites, I note
>
> - if the caller of /bin/sh is ROOT, the capabities are inherited. Thus
> my request has no relevance in that case.
You're misinterpreting the empirical evidence.
If the caller is root, then capabilities are not "inherited." Rather,
if you are running in !issecure(SECURE_NOROOT) (which everyone is right
now), then we fake an all-powerful root by filling the file capability
sets at exec. So it's not that the task's capabliities are inherited.
Rather, it's that as the capabilities are recalculated, we pretend that
the file had full capability sets.
That's very different, but leads to the same results in your example
above.
> - if the caller does first setuid to non-root, the capabilities are
> cleared, unless KEEP_CAPS is explicitly set. Thus, my requested
> change would not cause problems with your buggy mail program.
>
> - if the caller goes through all the trouble of setting KEEP_CAPS and
> changing to non-root, I would expect it to be sensible that the
> caller also intends the execve code to inherit capabilities.
>
> As an experiment and example, I made a small patch to Ubuntu 2.6.24
> kernel, to make it work like I think it should: if KEEP_CAPS is set,
> they are inherited (see at end).
>
> I'm ok with the current kernel code, which seems to clear the
> KEEP_CAPS on execve. Thus, each executable must again re-enable it, if
> it needs capabilities inherited further...
>
>
> > So in the capabilities model, the capabilities do *not* inherit unless
> > the a particular file explicitly states that it should inherit the
> > capabilities. It's the principle of least privilege taken to its
> > logical conclusion.
>
> I'm looking at network oriented devices, where executables or
> interpreted content from network sources is executed by helper
> applications or directly as executables. Depending on the source of
> the "code", the helper application or the downloaded exectuable may be
> allowed to run with different permissions (capabilities, uid/gid
> etc). [For example, look at android security model with manifests of
> requested and declared permissions, but applied to everything
> downloaded or installed].
>
> File capabilities (nor selinux) won't work, because the "helper
> applications" need to be executed with different capabilities and
> permissions, depending on the "manifests" of the downloaded
> "code". Obviously, serious permissions are granted only to properly
> verified "code" (signed).
Both capabilities and selinux will allow:
1. the same binaries to be executed with different
privileges/permissions depending on the context of
the caller.
2. different binaries to be executed by the same caller
resulting in different privileges/permissions.
(that answers your next question)
> [Any ideas how selinux would help to enforce a permission which is
> dynamically defined by installing application?]
-serge