Re: implement-file-posix-capabilities.patch
--- Andrew Morgan <[EMAIL PROTECTED]> wrote: > no one has yet actually > given an example of where fE being richer than a simple binary helps > anything. Until I see an example, I'm going to hold the position that > this is needless "complexity". The only counter to this argument is that you now have a different structure on files than on processes. Not a major issue, but one structure to describe capability sets is less complex than two. That way you can have one function to print a capset, regardless of its coming off a file or a process. Just a thought. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> 1. Exactly Andrew describes. Once userspace switches to a new cap
> format, an older kernel simply won't support them
Mmm. Let me see. I think I prefer this one! :-)
> 2. As Andrew describes, but also encode the version number into the
> capability name, i.e. security.capability.v3. Now userspace can
> optionally tack on more than one capability version to be backward
> compatible.
If you have a significant legacy of use of earlier versions, I guess
this makes sense. However, given the experimental nature of this support
(it will be a while before the user space support for this is
secure/robust), I'm not all that concerned about legacy support.
> 3. Somewhat different than Andrew describes. We mandate that any
> capability version N+1 consist of
>
> struct vfs_cap_data {
> __u32 magic;
> capability_version_1;
> capability_version_2;
> ...
> capability_version_N;
> capability_version_N+1;
> };
Ugh. I don't like this. It presumes that the kernel will get more and
more complicated over time. Please don't do this one.
> Or, for brevity,
>
> struct vfs_cap_data {
> __u32 first_magic;
> __u32 last_magic;
> capability_version_first;
> ...
> capability_version_last;
> };
>
> 4. Stick to the current plan, where switching to 64-bit caps will be
> done as
>
> struct vfs_cap_data_disk {
> __le32 version;
> __le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
> };
While asserting that it is more flexible etc., no one has yet actually
given an example of where fE being richer than a simple binary helps
anything. Until I see an example, I'm going to hold the position that
this is needless "complexity".
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGjBFXmwytjiwfWMwRAofJAKCXX2GkN39o45fCQmxpNpZIEVH8EgCeLaDy
AoWZNj/1MqT7oayabxUhIn8=
=OSBu
-END PGP SIGNATURE-
-
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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
1. Exactly Andrew describes. Once userspace switches to a new cap
format, an older kernel simply won't support them
Mmm. Let me see. I think I prefer this one! :-)
2. As Andrew describes, but also encode the version number into the
capability name, i.e. security.capability.v3. Now userspace can
optionally tack on more than one capability version to be backward
compatible.
If you have a significant legacy of use of earlier versions, I guess
this makes sense. However, given the experimental nature of this support
(it will be a while before the user space support for this is
secure/robust), I'm not all that concerned about legacy support.
3. Somewhat different than Andrew describes. We mandate that any
capability version N+1 consist of
struct vfs_cap_data {
__u32 magic;
capability_version_1;
capability_version_2;
...
capability_version_N;
capability_version_N+1;
};
Ugh. I don't like this. It presumes that the kernel will get more and
more complicated over time. Please don't do this one.
Or, for brevity,
struct vfs_cap_data {
__u32 first_magic;
__u32 last_magic;
capability_version_first;
...
capability_version_last;
};
4. Stick to the current plan, where switching to 64-bit caps will be
done as
struct vfs_cap_data_disk {
__le32 version;
__le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
};
While asserting that it is more flexible etc., no one has yet actually
given an example of where fE being richer than a simple binary helps
anything. Until I see an example, I'm going to hold the position that
this is needless complexity.
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGjBFXmwytjiwfWMwRAofJAKCXX2GkN39o45fCQmxpNpZIEVH8EgCeLaDy
AoWZNj/1MqT7oayabxUhIn8=
=OSBu
-END PGP SIGNATURE-
-
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/
Re: implement-file-posix-capabilities.patch
--- Andrew Morgan [EMAIL PROTECTED] wrote: no one has yet actually given an example of where fE being richer than a simple binary helps anything. Until I see an example, I'm going to hold the position that this is needless complexity. The only counter to this argument is that you now have a different structure on files than on processes. Not a major issue, but one structure to describe capability sets is less complex than two. That way you can have one function to print a capset, regardless of its coming off a file or a process. Just a thought. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
All,
Regarding future/backward compatibility of file capabilities:
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
...
> #define VFS_CAP_REVISION_MASK 0xFF00
> #define VFS_CAP_REVISION 0x0100
>
> #define VFS_CAP_FLAGS_MASK~VFS_CAP_REVISION_MASK
> #define VFS_CAP_FLAGS_EFFECTIVE 0x01
>
> struct vfs_cap_data {
> __u32 magic_etc;
> struct {
> __u32 permitted; /* Little endian */
> __u32 inheritable; /* Little endian */
> } data[1];
> };
...
> 3) The cap_from_disk() interface checking needs some work Most
> notably, size must be greater than sizeof(u32) or the very first line
> will do something nasty... I'd recommend you use code like this:
>
> [...] cap_from_disk(...)
> {
>if (size != sizeof(struct vfs_cap_data)) {
> printk(KERN_WARNING "%s: invalid cap size %d for file %s\n",
>__FUNCTION__, size, bprm->filename);
> return -EINVAL;
>}
>
>switch ((version & VFS_CAP_REVISION_MASK)) {
>case VFS_CAP_REVISION:
> bprm->cap_effective = (version & VFS_CAP_FLAGS_EFFECTIVE)
> ? CAP_FULL_SET : CAP_EMPTY_SET;
> bprm->cap_permitted =
> to_cap_t( le32_to_cpu(dcap->data[0].permitted) );
> bprm->cap_inheritable =
> to_cap_t( le32_to_cpu(dcap->data[0].inheritable) );
> return 0;
>default:
> return -EINVAL;
>}
> }
>
> Basically, I don't believe in designing a secure interface to be forward
> compatible - things never work out that way and the legacy you are
> implicitly committing to will haunt you in the future... FWIW I've known
> a few x86 MSR designers over the years and each one has made this
> mistake at least once... The future is uncertain, so don't trust it will
> look the way you want it to. ;-)
There are a few obvious approaches we can take:
1. Exactly Andrew describes. Once userspace switches to a new cap
format, an older kernel simply won't support them
2. As Andrew describes, but also encode the version number into the
capability name, i.e. security.capability.v3. Now userspace can
optionally tack on more than one capability version to be backward
compatible.
3. Somewhat different than Andrew describes. We mandate that any
capability version N+1 consist of
struct vfs_cap_data {
__u32 magic;
capability_version_1;
capability_version_2;
...
capability_version_N;
capability_version_N+1;
};
Or, for brevity,
struct vfs_cap_data {
__u32 first_magic;
__u32 last_magic;
capability_version_first;
...
capability_version_last;
};
4. Stick to the current plan, where switching to 64-bit caps will be
done as
struct vfs_cap_data_disk {
__le32 version;
__le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
};
What would people prefer?
thanks,
-serge
-
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/
Re: implement-file-posix-capabilities.patch
All,
Regarding future/backward compatibility of file capabilities:
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
...
#define VFS_CAP_REVISION_MASK 0xFF00
#define VFS_CAP_REVISION 0x0100
#define VFS_CAP_FLAGS_MASK~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x01
struct vfs_cap_data {
__u32 magic_etc;
struct {
__u32 permitted; /* Little endian */
__u32 inheritable; /* Little endian */
} data[1];
};
...
3) The cap_from_disk() interface checking needs some work Most
notably, size must be greater than sizeof(u32) or the very first line
will do something nasty... I'd recommend you use code like this:
[...] cap_from_disk(...)
{
if (size != sizeof(struct vfs_cap_data)) {
printk(KERN_WARNING %s: invalid cap size %d for file %s\n,
__FUNCTION__, size, bprm-filename);
return -EINVAL;
}
switch ((version VFS_CAP_REVISION_MASK)) {
case VFS_CAP_REVISION:
bprm-cap_effective = (version VFS_CAP_FLAGS_EFFECTIVE)
? CAP_FULL_SET : CAP_EMPTY_SET;
bprm-cap_permitted =
to_cap_t( le32_to_cpu(dcap-data[0].permitted) );
bprm-cap_inheritable =
to_cap_t( le32_to_cpu(dcap-data[0].inheritable) );
return 0;
default:
return -EINVAL;
}
}
Basically, I don't believe in designing a secure interface to be forward
compatible - things never work out that way and the legacy you are
implicitly committing to will haunt you in the future... FWIW I've known
a few x86 MSR designers over the years and each one has made this
mistake at least once... The future is uncertain, so don't trust it will
look the way you want it to. ;-)
There are a few obvious approaches we can take:
1. Exactly Andrew describes. Once userspace switches to a new cap
format, an older kernel simply won't support them
2. As Andrew describes, but also encode the version number into the
capability name, i.e. security.capability.v3. Now userspace can
optionally tack on more than one capability version to be backward
compatible.
3. Somewhat different than Andrew describes. We mandate that any
capability version N+1 consist of
struct vfs_cap_data {
__u32 magic;
capability_version_1;
capability_version_2;
...
capability_version_N;
capability_version_N+1;
};
Or, for brevity,
struct vfs_cap_data {
__u32 first_magic;
__u32 last_magic;
capability_version_first;
...
capability_version_last;
};
4. Stick to the current plan, where switching to 64-bit caps will be
done as
struct vfs_cap_data_disk {
__le32 version;
__le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
};
What would people prefer?
thanks,
-serge
-
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/
Re: implement-file-posix-capabilities.patch
--- Andrew Morgan <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Casey Schaufler wrote: > >> Would there be a difference between that and setting either fI or fP > >> (depending on your intent) to those caps, and setting fE=1 in Andrew's > >> scheme? > > > > Arg, you're making me think. The POSIX group went through this, > > let me see if I can reconstruct the logic. > > > > The main issue is one if there being a possible case where you > > have a capability ignorant program that you want to exec with > > a different fP and fE. On first glance it seems that since the > > program is capability ignorant it can't matter. But what if your > > capability ignorant program exec's a capability aware program > > to perform a helper function? You may well want the first program > > to have a capability that it does not use in fP (but not fE) > > to pass along to the helper program. True, you could probably > > I'm not sure I've quite flogged this horse to death yet.. :-) > > In my other reply, I quoted the rules. Here they are again: > > pI' = pI > pP' = (X & fP) | (pI & fI) > pE' = pP' & fE > > If program A exec()utes helper program B, then the only capabilities > (p*') that B can get from A are a subset of A's pI set. > > If A doesn't know about capabilities, then nothing about the fE value > associated with the A program file can alter A's pI set and thus affect > B. That is, nothing about the fE or fP value used to exec()ute A gets > propagated through a subsequent exec() to B. > > So far as I can see, to achieve the helper program support you are > describing, the value of pI that program A (and thus program B) inherits > will have to contain the relevant capabilities, and B will have to have > a sufficient fI value to pick them up... > > Incidentally, this is also where my request that we require (pP' >= fP) > be true comes in. If a helper program (which may also be a legacy > program) is used in a way that it is configured (via fP) to have powers > that are denied to it (via X=cap_bset etc.,) then it should simply not > be permitted to run (-EPERM). It should not have the opportunity to > silently confuse itself (as was the case with sendmail when we tried to > emulate setuid-0 behavior with capabilities a few years back). > > > come up with a way to set the capabilities on the helper program > > to account for this use, but there may be design and security > > constraints that make doing so complicated. > > I've not seen anything yet to make be believe there is a case for a > non-single bit fE value... Its a little ironic that I read all of the > rationale I've been espousing in POSIX drafts - so far as I'm aware the > only detail I'm mixing in there is the (pP' >= fP), -EPERM, thing. > > If you or anyone can cite some counter examples, please do! Nope, I'm fresh out. If the reality is that you get no added value with a vector over a scalar I'm good with either scheme. Looks like you've done the dilegance. I see no flaws in your logic. I suppose I could argue for the vector in terms of compatability with Irix, but I'll leave that to those who might care. Thank you for both the work and the clear explainations. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Casey Schaufler wrote: > >> Would there be a difference between that and setting either fI or fP > >> (depending on your intent) to those caps, and setting fE=1 in Andrew's > >> scheme? > > > > Arg, you're making me think. The POSIX group went through this, > > let me see if I can reconstruct the logic. > > > > The main issue is one if there being a possible case where you > > have a capability ignorant program that you want to exec with > > a different fP and fE. On first glance it seems that since the > > program is capability ignorant it can't matter. But what if your > > capability ignorant program exec's a capability aware program > > to perform a helper function? You may well want the first program > > to have a capability that it does not use in fP (but not fE) > > to pass along to the helper program. True, you could probably > > I'm not sure I've quite flogged this horse to death yet.. :-) > > In my other reply, I quoted the rules. Here they are again: > > pI' = pI > pP' = (X & fP) | (pI & fI) > pE' = pP' & fE > > If program A exec()utes helper program B, then the only capabilities > (p*') that B can get from A are a subset of A's pI set. > > If A doesn't know about capabilities, then nothing about the fE value > associated with the A program file can alter A's pI set and thus affect > B. That is, nothing about the fE or fP value used to exec()ute A gets > propagated through a subsequent exec() to B. > > So far as I can see, to achieve the helper program support you are > describing, the value of pI that program A (and thus program B) inherits > will have to contain the relevant capabilities, and B will have to have > a sufficient fI value to pick them up... > > Incidentally, this is also where my request that we require (pP' >= fP) > be true comes in. If a helper program (which may also be a legacy That was going to be my next thing to look at, btw. > program) is used in a way that it is configured (via fP) to have powers > that are denied to it (via X=cap_bset etc.,) then it should simply not > be permitted to run (-EPERM). It should not have the opportunity to > silently confuse itself (as was the case with sendmail when we tried to > emulate setuid-0 behavior with capabilities a few years back). > > > come up with a way to set the capabilities on the helper program > > to account for this use, but there may be design and security > > constraints that make doing so complicated. > > I've not seen anything yet to make be believe there is a case for a > non-single bit fE value... Its a little ironic that I read all of the > rationale I've been espousing in POSIX drafts - so far as I'm aware the > only detail I'm mixing in there is the (pP' >= fP), -EPERM, thing. > > If you or anyone can cite some counter examples, please do! Not really. But, your argument is: fE can only be used to create a different initial pE' than pP'. If the binary doesn't know about capabilities, then you would never want to do that since it won't change it's pE', and therefore it's pP' is meaningless once pE' is set. If the binary does know about capabilities, then it can change it's pE' within the bounds of it's pP' whenever it wants, so we may want to set pE' to 0 at start, but having pE' be just a subset of pP' has no advantage since the binary can set pE' to the subset when it wants. Now, *my* argument :) is that: While there is no particular advantage (that I can think of) to having the bitmap pE', there is also no disadvantage, and it produces kernel code closer to the actual equations usually seen. In the course of this discussion, the two advantages I've seen which I'll concede to you are: 1. the resulting equations may be easier to read/understand, just bc it's one less bitmask operation whose purpose to try to understand. But I'm not certain. 2. Improper setting of fE *could* in theory cause another hard to diagnose sendmail-type vulnerability, by having fP set to the right value, but fE to the wrong value. Though that is stretching things a bit. The change in xattr format offsets those, which is why I like the idea of just having the setfcaps program understand 'on=e' and 'off=e' (where on is of course just an alias for 'all'), but keeping the kernel code the same. -serge - 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/
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: Would there be a difference between that and setting either fI or fP (depending on your intent) to those caps, and setting fE=1 in Andrew's scheme? Arg, you're making me think. The POSIX group went through this, let me see if I can reconstruct the logic. The main issue is one if there being a possible case where you have a capability ignorant program that you want to exec with a different fP and fE. On first glance it seems that since the program is capability ignorant it can't matter. But what if your capability ignorant program exec's a capability aware program to perform a helper function? You may well want the first program to have a capability that it does not use in fP (but not fE) to pass along to the helper program. True, you could probably I'm not sure I've quite flogged this horse to death yet.. :-) In my other reply, I quoted the rules. Here they are again: pI' = pI pP' = (X fP) | (pI fI) pE' = pP' fE If program A exec()utes helper program B, then the only capabilities (p*') that B can get from A are a subset of A's pI set. If A doesn't know about capabilities, then nothing about the fE value associated with the A program file can alter A's pI set and thus affect B. That is, nothing about the fE or fP value used to exec()ute A gets propagated through a subsequent exec() to B. So far as I can see, to achieve the helper program support you are describing, the value of pI that program A (and thus program B) inherits will have to contain the relevant capabilities, and B will have to have a sufficient fI value to pick them up... Incidentally, this is also where my request that we require (pP' = fP) be true comes in. If a helper program (which may also be a legacy That was going to be my next thing to look at, btw. program) is used in a way that it is configured (via fP) to have powers that are denied to it (via X=cap_bset etc.,) then it should simply not be permitted to run (-EPERM). It should not have the opportunity to silently confuse itself (as was the case with sendmail when we tried to emulate setuid-0 behavior with capabilities a few years back). come up with a way to set the capabilities on the helper program to account for this use, but there may be design and security constraints that make doing so complicated. I've not seen anything yet to make be believe there is a case for a non-single bit fE value... Its a little ironic that I read all of the rationale I've been espousing in POSIX drafts - so far as I'm aware the only detail I'm mixing in there is the (pP' = fP), -EPERM, thing. If you or anyone can cite some counter examples, please do! Not really. But, your argument is: fE can only be used to create a different initial pE' than pP'. If the binary doesn't know about capabilities, then you would never want to do that since it won't change it's pE', and therefore it's pP' is meaningless once pE' is set. If the binary does know about capabilities, then it can change it's pE' within the bounds of it's pP' whenever it wants, so we may want to set pE' to 0 at start, but having pE' be just a subset of pP' has no advantage since the binary can set pE' to the subset when it wants. Now, *my* argument :) is that: While there is no particular advantage (that I can think of) to having the bitmap pE', there is also no disadvantage, and it produces kernel code closer to the actual equations usually seen. In the course of this discussion, the two advantages I've seen which I'll concede to you are: 1. the resulting equations may be easier to read/understand, just bc it's one less bitmask operation whose purpose to try to understand. But I'm not certain. 2. Improper setting of fE *could* in theory cause another hard to diagnose sendmail-type vulnerability, by having fP set to the right value, but fE to the wrong value. Though that is stretching things a bit. The change in xattr format offsets those, which is why I like the idea of just having the setfcaps program understand 'on=e' and 'off=e' (where on is of course just an alias for 'all'), but keeping the kernel code the same. -serge - 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/
Re: implement-file-posix-capabilities.patch
--- Andrew Morgan [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: Would there be a difference between that and setting either fI or fP (depending on your intent) to those caps, and setting fE=1 in Andrew's scheme? Arg, you're making me think. The POSIX group went through this, let me see if I can reconstruct the logic. The main issue is one if there being a possible case where you have a capability ignorant program that you want to exec with a different fP and fE. On first glance it seems that since the program is capability ignorant it can't matter. But what if your capability ignorant program exec's a capability aware program to perform a helper function? You may well want the first program to have a capability that it does not use in fP (but not fE) to pass along to the helper program. True, you could probably I'm not sure I've quite flogged this horse to death yet.. :-) In my other reply, I quoted the rules. Here they are again: pI' = pI pP' = (X fP) | (pI fI) pE' = pP' fE If program A exec()utes helper program B, then the only capabilities (p*') that B can get from A are a subset of A's pI set. If A doesn't know about capabilities, then nothing about the fE value associated with the A program file can alter A's pI set and thus affect B. That is, nothing about the fE or fP value used to exec()ute A gets propagated through a subsequent exec() to B. So far as I can see, to achieve the helper program support you are describing, the value of pI that program A (and thus program B) inherits will have to contain the relevant capabilities, and B will have to have a sufficient fI value to pick them up... Incidentally, this is also where my request that we require (pP' = fP) be true comes in. If a helper program (which may also be a legacy program) is used in a way that it is configured (via fP) to have powers that are denied to it (via X=cap_bset etc.,) then it should simply not be permitted to run (-EPERM). It should not have the opportunity to silently confuse itself (as was the case with sendmail when we tried to emulate setuid-0 behavior with capabilities a few years back). come up with a way to set the capabilities on the helper program to account for this use, but there may be design and security constraints that make doing so complicated. I've not seen anything yet to make be believe there is a case for a non-single bit fE value... Its a little ironic that I read all of the rationale I've been espousing in POSIX drafts - so far as I'm aware the only detail I'm mixing in there is the (pP' = fP), -EPERM, thing. If you or anyone can cite some counter examples, please do! Nope, I'm fresh out. If the reality is that you get no added value with a vector over a scalar I'm good with either scheme. Looks like you've done the dilegance. I see no flaws in your logic. I suppose I could argue for the vector in terms of compatability with Irix, but I'll leave that to those who might care. Thank you for both the work and the clear explainations. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: >> Would there be a difference between that and setting either fI or fP >> (depending on your intent) to those caps, and setting fE=1 in Andrew's >> scheme? > > Arg, you're making me think. The POSIX group went through this, > let me see if I can reconstruct the logic. > > The main issue is one if there being a possible case where you > have a capability ignorant program that you want to exec with > a different fP and fE. On first glance it seems that since the > program is capability ignorant it can't matter. But what if your > capability ignorant program exec's a capability aware program > to perform a helper function? You may well want the first program > to have a capability that it does not use in fP (but not fE) > to pass along to the helper program. True, you could probably I'm not sure I've quite flogged this horse to death yet.. :-) In my other reply, I quoted the rules. Here they are again: pI' = pI pP' = (X & fP) | (pI & fI) pE' = pP' & fE If program A exec()utes helper program B, then the only capabilities (p*') that B can get from A are a subset of A's pI set. If A doesn't know about capabilities, then nothing about the fE value associated with the A program file can alter A's pI set and thus affect B. That is, nothing about the fE or fP value used to exec()ute A gets propagated through a subsequent exec() to B. So far as I can see, to achieve the helper program support you are describing, the value of pI that program A (and thus program B) inherits will have to contain the relevant capabilities, and B will have to have a sufficient fI value to pick them up... Incidentally, this is also where my request that we require (pP' >= fP) be true comes in. If a helper program (which may also be a legacy program) is used in a way that it is configured (via fP) to have powers that are denied to it (via X=cap_bset etc.,) then it should simply not be permitted to run (-EPERM). It should not have the opportunity to silently confuse itself (as was the case with sendmail when we tried to emulate setuid-0 behavior with capabilities a few years back). > come up with a way to set the capabilities on the helper program > to account for this use, but there may be design and security > constraints that make doing so complicated. I've not seen anything yet to make be believe there is a case for a non-single bit fE value... Its a little ironic that I read all of the rationale I've been espousing in POSIX drafts - so far as I'm aware the only detail I'm mixing in there is the (pP' >= fP), -EPERM, thing. If you or anyone can cite some counter examples, please do! Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGhJjxQheEq9QabfIRAmyLAKCUxirmAuS4VM0U+9HloeOF6cKt2gCgi/fh ElhM1CISM4a+e0umBjK9GV0= =Vrqj -END PGP SIGNATURE- - 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/
Re: implement-file-posix-capabilities.patch
--- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Casey Schaufler ([EMAIL PROTECTED]): > > > > --- Andrew Morgan <[EMAIL PROTECTED]> wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Serge E. Hallyn wrote: > > > >> Does that explain it? > > > > > > > > Yes, thanks, but then it still could come in handy to have fE be a full > > > > bitset, so the application gets some eff caps automatically, while > > > > others it has to manually set... > > > > > > [We touched on this a number of emails back.] > > > > > > If an application is capability aware, it can manipulate its own > > > capabilities and should have fE=0. > > > > > > If an application is not capability aware, it needs to have *all* of its > > > capabilities enabled at exec() time. Otherwise, it won't work. > > > > The intent of the fE vector in the POSIX draft is that those capabilities > > are set on exec (lower vectors permitting). There are cases where it > > does make sense to raise just some (e.g. ping). > > > > > The only reason for having an fE bitmap is to allow a capability-aware > > > program (you really trust to do its privileged operations carefully) to > > > be lazy and get some of its capabilities raised for free. Perhaps you > > > can clarify why this is a desirable thing? :-) > > > > No, it's to allow you to grant a subset of the available capabilities > > to a program that is not aware of capabilities. You can give "date" > > the capability to reset the clock without giving it the capability > > to remove other people's files without changing the code or running > > it setuid. > > Would there be a difference between that and setting either fI or fP > (depending on your intent) to those caps, and setting fE=1 in Andrew's > scheme? Arg, you're making me think. The POSIX group went through this, let me see if I can reconstruct the logic. The main issue is one if there being a possible case where you have a capability ignorant program that you want to exec with a different fP and fE. On first glance it seems that since the program is capability ignorant it can't matter. But what if your capability ignorant program exec's a capability aware program to perform a helper function? You may well want the first program to have a capability that it does not use in fP (but not fE) to pass along to the helper program. True, you could probably come up with a way to set the capabilities on the helper program to account for this use, but there may be design and security constraints that make doing so complicated. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: >> The only reason for having an fE bitmap is to allow a capability-aware >> program (you really trust to do its privileged operations carefully) to >> be lazy and get some of its capabilities raised for free. Perhaps you >> can clarify why this is a desirable thing? :-) > > No, it's to allow you to grant a subset of the available capabilities > to a program that is not aware of capabilities. You can give "date" > the capability to reset the clock without giving it the capability > to remove other people's files without changing the code or running > it setuid. This is precisely what fE = 0 or ~0 provides. Recall, an exec()'d program gets its p*' capabilities from a convolution of its exec()er's inheritable set (pI) *and* the file's capabilities (fI,fP,fE): pI' = pI pP' = (X & fP) | (pI & fI) pE' = pP' & fE [Linux essentially has cap_bset for X.] The fine-grain ability for ping to do its thing without becoming powerful enough to load a kernel module, for example, is facilitated by the "pP' &" part of the derivation of pE' (and not simply the unfiltered value of fE!). As I said before, either the program knows how to raise and lower bits in its pE set, or it doesn't. In the former case, fE=0. In the latter case, fE=~0 will ensure that it gets all of the capabilities it is permitted to exercise at time of execution. Could you cite some examples of where this position is unreasonable? Thanks Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGg9i1+bHCR3gb8jsRAvViAJ9T5x1fHrLGF4niRq7VhRqg4sej3wCgxkom oAFQEQwLkd/D6J5gi7Fb3Ww= =+ZLb -END PGP SIGNATURE- - 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/
Re: implement-file-posix-capabilities.patch
Quoting Casey Schaufler ([EMAIL PROTECTED]): > > --- Andrew Morgan <[EMAIL PROTECTED]> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Serge E. Hallyn wrote: > > >> Does that explain it? > > > > > > Yes, thanks, but then it still could come in handy to have fE be a full > > > bitset, so the application gets some eff caps automatically, while > > > others it has to manually set... > > > > [We touched on this a number of emails back.] > > > > If an application is capability aware, it can manipulate its own > > capabilities and should have fE=0. > > > > If an application is not capability aware, it needs to have *all* of its > > capabilities enabled at exec() time. Otherwise, it won't work. > > The intent of the fE vector in the POSIX draft is that those capabilities > are set on exec (lower vectors permitting). There are cases where it > does make sense to raise just some (e.g. ping). > > > The only reason for having an fE bitmap is to allow a capability-aware > > program (you really trust to do its privileged operations carefully) to > > be lazy and get some of its capabilities raised for free. Perhaps you > > can clarify why this is a desirable thing? :-) > > No, it's to allow you to grant a subset of the available capabilities > to a program that is not aware of capabilities. You can give "date" > the capability to reset the clock without giving it the capability > to remove other people's files without changing the code or running > it setuid. Would there be a difference between that and setting either fI or fP (depending on your intent) to those caps, and setting fE=1 in Andrew's scheme? thanks, -serge - 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/
Re: implement-file-posix-capabilities.patch
--- Andrew Morgan <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> Does that explain it? > > > > Yes, thanks, but then it still could come in handy to have fE be a full > > bitset, so the application gets some eff caps automatically, while > > others it has to manually set... > > [We touched on this a number of emails back.] > > If an application is capability aware, it can manipulate its own > capabilities and should have fE=0. > > If an application is not capability aware, it needs to have *all* of its > capabilities enabled at exec() time. Otherwise, it won't work. The intent of the fE vector in the POSIX draft is that those capabilities are set on exec (lower vectors permitting). There are cases where it does make sense to raise just some (e.g. ping). > The only reason for having an fE bitmap is to allow a capability-aware > program (you really trust to do its privileged operations carefully) to > be lazy and get some of its capabilities raised for free. Perhaps you > can clarify why this is a desirable thing? :-) No, it's to allow you to grant a subset of the available capabilities to a program that is not aware of capabilities. You can give "date" the capability to reset the clock without giving it the capability to remove other people's files without changing the code or running it setuid. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> Does that explain it? > > > > Yes, thanks, but then it still could come in handy to have fE be a full > > bitset, so the application gets some eff caps automatically, while > > others it has to manually set... > > [We touched on this a number of emails back.] > > If an application is capability aware, it can manipulate its own > capabilities and should have fE=0. > > If an application is not capability aware, it needs to have *all* of its > capabilities enabled at exec() time. Otherwise, it won't work. > > The only reason for having an fE bitmap is to allow a capability-aware > program (you really trust to do its privileged operations carefully) to > be lazy and get some of its capabilities raised for free. Perhaps you > can clarify why this is a desirable thing? :-) Sure - because it doesn't hurt anything, someone just *might* find it useful one day, and mostly the three bitmaps just look a lot cleaner to me than hiding a bit inside the version field. There are a *few* people using this, and so a complete switch in format for no actual net gain seems wrong. If we want to fake fE to the user as being one bit we can do that through the setfcaps/getfcaps programs. There also are prior examples of doing it this way (i.e. Olaf Dietsche's implementation) OTOH I don't deny implementing it fully as you describe seems to make the intent of the code clearer to readers and maintainers. I guess maybe I'll give it a go and see what turns out. thanks, -serge - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: >> Does that explain it? > > Yes, thanks, but then it still could come in handy to have fE be a full > bitset, so the application gets some eff caps automatically, while > others it has to manually set... [We touched on this a number of emails back.] If an application is capability aware, it can manipulate its own capabilities and should have fE=0. If an application is not capability aware, it needs to have *all* of its capabilities enabled at exec() time. Otherwise, it won't work. The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGg1LqQheEq9QabfIRAo3BAKCO8QrfcKBNqhfnn2BHp8O/qDkgXgCgleEl xP7LZPU9Qn6AjqI3ZM3FZ+4= =urmz -END PGP SIGNATURE- - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: Does that explain it? Yes, thanks, but then it still could come in handy to have fE be a full bitset, so the application gets some eff caps automatically, while others it has to manually set... [We touched on this a number of emails back.] If an application is capability aware, it can manipulate its own capabilities and should have fE=0. If an application is not capability aware, it needs to have *all* of its capabilities enabled at exec() time. Otherwise, it won't work. The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGg1LqQheEq9QabfIRAo3BAKCO8QrfcKBNqhfnn2BHp8O/qDkgXgCgleEl xP7LZPU9Qn6AjqI3ZM3FZ+4= =urmz -END PGP SIGNATURE- - 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/
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: Does that explain it? Yes, thanks, but then it still could come in handy to have fE be a full bitset, so the application gets some eff caps automatically, while others it has to manually set... [We touched on this a number of emails back.] If an application is capability aware, it can manipulate its own capabilities and should have fE=0. If an application is not capability aware, it needs to have *all* of its capabilities enabled at exec() time. Otherwise, it won't work. The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) Sure - because it doesn't hurt anything, someone just *might* find it useful one day, and mostly the three bitmaps just look a lot cleaner to me than hiding a bit inside the version field. There are a *few* people using this, and so a complete switch in format for no actual net gain seems wrong. If we want to fake fE to the user as being one bit we can do that through the setfcaps/getfcaps programs. There also are prior examples of doing it this way (i.e. Olaf Dietsche's implementation) OTOH I don't deny implementing it fully as you describe seems to make the intent of the code clearer to readers and maintainers. I guess maybe I'll give it a go and see what turns out. thanks, -serge - 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/
Re: implement-file-posix-capabilities.patch
--- Andrew Morgan [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: Does that explain it? Yes, thanks, but then it still could come in handy to have fE be a full bitset, so the application gets some eff caps automatically, while others it has to manually set... [We touched on this a number of emails back.] If an application is capability aware, it can manipulate its own capabilities and should have fE=0. If an application is not capability aware, it needs to have *all* of its capabilities enabled at exec() time. Otherwise, it won't work. The intent of the fE vector in the POSIX draft is that those capabilities are set on exec (lower vectors permitting). There are cases where it does make sense to raise just some (e.g. ping). The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) No, it's to allow you to grant a subset of the available capabilities to a program that is not aware of capabilities. You can give date the capability to reset the clock without giving it the capability to remove other people's files without changing the code or running it setuid. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
Quoting Casey Schaufler ([EMAIL PROTECTED]): --- Andrew Morgan [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: Does that explain it? Yes, thanks, but then it still could come in handy to have fE be a full bitset, so the application gets some eff caps automatically, while others it has to manually set... [We touched on this a number of emails back.] If an application is capability aware, it can manipulate its own capabilities and should have fE=0. If an application is not capability aware, it needs to have *all* of its capabilities enabled at exec() time. Otherwise, it won't work. The intent of the fE vector in the POSIX draft is that those capabilities are set on exec (lower vectors permitting). There are cases where it does make sense to raise just some (e.g. ping). The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) No, it's to allow you to grant a subset of the available capabilities to a program that is not aware of capabilities. You can give date the capability to reset the clock without giving it the capability to remove other people's files without changing the code or running it setuid. Would there be a difference between that and setting either fI or fP (depending on your intent) to those caps, and setting fE=1 in Andrew's scheme? thanks, -serge - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) No, it's to allow you to grant a subset of the available capabilities to a program that is not aware of capabilities. You can give date the capability to reset the clock without giving it the capability to remove other people's files without changing the code or running it setuid. This is precisely what fE = 0 or ~0 provides. Recall, an exec()'d program gets its p*' capabilities from a convolution of its exec()er's inheritable set (pI) *and* the file's capabilities (fI,fP,fE): pI' = pI pP' = (X fP) | (pI fI) pE' = pP' fE [Linux essentially has cap_bset for X.] The fine-grain ability for ping to do its thing without becoming powerful enough to load a kernel module, for example, is facilitated by the pP' part of the derivation of pE' (and not simply the unfiltered value of fE!). As I said before, either the program knows how to raise and lower bits in its pE set, or it doesn't. In the former case, fE=0. In the latter case, fE=~0 will ensure that it gets all of the capabilities it is permitted to exercise at time of execution. Could you cite some examples of where this position is unreasonable? Thanks Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGg9i1+bHCR3gb8jsRAvViAJ9T5x1fHrLGF4niRq7VhRqg4sej3wCgxkom oAFQEQwLkd/D6J5gi7Fb3Ww= =+ZLb -END PGP SIGNATURE- - 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/
Re: implement-file-posix-capabilities.patch
--- Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Casey Schaufler ([EMAIL PROTECTED]): --- Andrew Morgan [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: Does that explain it? Yes, thanks, but then it still could come in handy to have fE be a full bitset, so the application gets some eff caps automatically, while others it has to manually set... [We touched on this a number of emails back.] If an application is capability aware, it can manipulate its own capabilities and should have fE=0. If an application is not capability aware, it needs to have *all* of its capabilities enabled at exec() time. Otherwise, it won't work. The intent of the fE vector in the POSIX draft is that those capabilities are set on exec (lower vectors permitting). There are cases where it does make sense to raise just some (e.g. ping). The only reason for having an fE bitmap is to allow a capability-aware program (you really trust to do its privileged operations carefully) to be lazy and get some of its capabilities raised for free. Perhaps you can clarify why this is a desirable thing? :-) No, it's to allow you to grant a subset of the available capabilities to a program that is not aware of capabilities. You can give date the capability to reset the clock without giving it the capability to remove other people's files without changing the code or running it setuid. Would there be a difference between that and setting either fI or fP (depending on your intent) to those caps, and setting fE=1 in Andrew's scheme? Arg, you're making me think. The POSIX group went through this, let me see if I can reconstruct the logic. The main issue is one if there being a possible case where you have a capability ignorant program that you want to exec with a different fP and fE. On first glance it seems that since the program is capability ignorant it can't matter. But what if your capability ignorant program exec's a capability aware program to perform a helper function? You may well want the first program to have a capability that it does not use in fP (but not fE) to pass along to the helper program. True, you could probably come up with a way to set the capabilities on the helper program to account for this use, but there may be design and security constraints that make doing so complicated. Casey Schaufler [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: Would there be a difference between that and setting either fI or fP (depending on your intent) to those caps, and setting fE=1 in Andrew's scheme? Arg, you're making me think. The POSIX group went through this, let me see if I can reconstruct the logic. The main issue is one if there being a possible case where you have a capability ignorant program that you want to exec with a different fP and fE. On first glance it seems that since the program is capability ignorant it can't matter. But what if your capability ignorant program exec's a capability aware program to perform a helper function? You may well want the first program to have a capability that it does not use in fP (but not fE) to pass along to the helper program. True, you could probably I'm not sure I've quite flogged this horse to death yet.. :-) In my other reply, I quoted the rules. Here they are again: pI' = pI pP' = (X fP) | (pI fI) pE' = pP' fE If program A exec()utes helper program B, then the only capabilities (p*') that B can get from A are a subset of A's pI set. If A doesn't know about capabilities, then nothing about the fE value associated with the A program file can alter A's pI set and thus affect B. That is, nothing about the fE or fP value used to exec()ute A gets propagated through a subsequent exec() to B. So far as I can see, to achieve the helper program support you are describing, the value of pI that program A (and thus program B) inherits will have to contain the relevant capabilities, and B will have to have a sufficient fI value to pick them up... Incidentally, this is also where my request that we require (pP' = fP) be true comes in. If a helper program (which may also be a legacy program) is used in a way that it is configured (via fP) to have powers that are denied to it (via X=cap_bset etc.,) then it should simply not be permitted to run (-EPERM). It should not have the opportunity to silently confuse itself (as was the case with sendmail when we tried to emulate setuid-0 behavior with capabilities a few years back). come up with a way to set the capabilities on the helper program to account for this use, but there may be design and security constraints that make doing so complicated. I've not seen anything yet to make be believe there is a case for a non-single bit fE value... Its a little ironic that I read all of the rationale I've been espousing in POSIX drafts - so far as I'm aware the only detail I'm mixing in there is the (pP' = fP), -EPERM, thing. If you or anyone can cite some counter examples, please do! Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGhJjxQheEq9QabfIRAmyLAKCUxirmAuS4VM0U+9HloeOF6cKt2gCgi/fh ElhM1CISM4a+e0umBjK9GV0= =Vrqj -END PGP SIGNATURE- - 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/
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Serge E. Hallyn wrote:
> >
> >> I don't particularly mind, but can you point out any case where
> >> it is an advantage to have the one bit for f'E rather than just
> >> drop f'E altogether? Instead of having
> >
> >>f'I=something
> >>f'P=something
> >>f'E=off
> >
> >> we can always just remove the security.capability xattr. Right?
>
> No. Bear in mind that capabilities are all about trusting specific
> applications with privilege as opposed to trusting the superuser to not
> run dangerous applications.
>
> There are three situations, we'll take them in turn:
>
> - no capabilities (fP=fI=fE=0): this is for applications that are not
> intended to operate with privilege. Because of the way the capability
> convolution rules work, such a program can't execute with privilege. Period.
(Except that in Linux, with SECURE_NOROOT=0, root will be able to. With
SECURE_NOROOT=y it won't.)
> - with capabilities (fP and/or fI != 0), but fE=0 (off): this is for
> applications that are intended to operate with privilege, but they were
> designed to know about capabilities and they manipulate (raise and
> lower) capabilities as needed to do the things they do.
>
> - with capabilities, but fE=1 (on): this is a class of applications
> loosely called 'legacy'. They can use privilege to operate, but don't
> strictly need to know about it. For example, /bin/chown . Such a program
> will have fP=0,fI=CAP_CHOWN. Since the administrator sets
> fP=0,fI=CAP_CHOWN,fE=1 on the /bin/chown file, any process with
> CAP_CHOWN in its inheritable set (pI) can "exec /bin/chown" and have it
> do the thing historically reserved for the superuser...
>
> In some future world, the legacy fE bit may become unnecessary because
> every application will be rewritten to be careful about exercising
> privilege explicitly. In the meantime, the fE bit can be used to drop
> the setuid-0 bits from things like ping and traceroute.
>
> >> If there's a case where that does not suffice, then I have no objection
> >> to doing it this way.
>
> Does that explain it?
Yes, thanks, but then it still could come in handy to have fE be a full
bitset, so the application gets some eff caps automatically, while
others it has to manually set...
> > 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
> > whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
> > way too overloaded and this functionality is special.
> >
> >> The functionality is special, but someone with CAP_SYS_ADMIN can always
> >> unload the capability module and create the security.capability xattr
> >> using the dummy module.
>
> This argument leads down a rat hole. (As appears to have happened with
> the non-modularization LSM thread elsewhere...)
>
> The simple fact is that CAP_SYS_ADMIN is equivalent to every other
> capability in the system if it can be used to load any flavor of kernel
> module. Arguing that you don't need a capability for something because
> you can do it with CAP_SYS_ADMIN is very close to admitting that you
> prefer the superuser (uid=0) model.
Well no, it could also just be acknowledging that at some point some
better cap breakup should be attempted, though of course some amount of
"these caps can subvert that cap" will always be there.
But I'm not actually objecting :) I expect this will be the first of
the patches I whip up.
> >> If we do add this cap, do we want to make it apply to all security.*
> >> xattrs?
>
> I recommend limiting it to just capabilities.
>
> For now, you can leave the other security attributes with the
> CAP_SYS_ADMIN ("misc") capability. In the original 'POSIX' drafts, there
> is a separate notion of advisory and mandatory access control;
> leveraging different capabilities to override.
>
> > 3) The cap_from_disk() interface checking needs some work Most
> > notably, size must be greater than sizeof(u32) or the very first line
> > will do something nasty... I'd recommend you use code like this:
> >
> > [...] cap_from_disk(...)
> > {
> >if (size != sizeof(struct vfs_cap_data)) {
> [...]
> > mistake at least once... The future is uncertain, so don't trust it will
> > look the way you want it to. ;-)
> >
> >> Ok, so you're saying that when we do switch to 64-bit caps or some other
> >> evolution, we switch to completely separate logic based on the
> >> VFS_CAP_REVISION?
>
> Yes.
>
> >> That seems sane to me.
>
> You might also want to verify that unallocated bits hold the value
> 'zero'. Its funny what people do when they realize they can silently
> store bits in obscure places like this. That really messes up allocating
> bits in the future. Add a check that is something like:
>
> if (version & ~(VFS_CAP_REVISION_MASK|VFS_CAP_FLAGS_EFFECTIVE)) {
> return -EINVAL;
> }
I used to do that (except with a stupid loop), but let's say you update
your distro, but the
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
I don't particularly mind, but can you point out any case where
it is an advantage to have the one bit for f'E rather than just
drop f'E altogether? Instead of having
f'I=something
f'P=something
f'E=off
we can always just remove the security.capability xattr. Right?
No. Bear in mind that capabilities are all about trusting specific
applications with privilege as opposed to trusting the superuser to not
run dangerous applications.
There are three situations, we'll take them in turn:
- no capabilities (fP=fI=fE=0): this is for applications that are not
intended to operate with privilege. Because of the way the capability
convolution rules work, such a program can't execute with privilege. Period.
(Except that in Linux, with SECURE_NOROOT=0, root will be able to. With
SECURE_NOROOT=y it won't.)
- with capabilities (fP and/or fI != 0), but fE=0 (off): this is for
applications that are intended to operate with privilege, but they were
designed to know about capabilities and they manipulate (raise and
lower) capabilities as needed to do the things they do.
- with capabilities, but fE=1 (on): this is a class of applications
loosely called 'legacy'. They can use privilege to operate, but don't
strictly need to know about it. For example, /bin/chown . Such a program
will have fP=0,fI=CAP_CHOWN. Since the administrator sets
fP=0,fI=CAP_CHOWN,fE=1 on the /bin/chown file, any process with
CAP_CHOWN in its inheritable set (pI) can exec /bin/chown and have it
do the thing historically reserved for the superuser...
In some future world, the legacy fE bit may become unnecessary because
every application will be rewritten to be careful about exercising
privilege explicitly. In the meantime, the fE bit can be used to drop
the setuid-0 bits from things like ping and traceroute.
If there's a case where that does not suffice, then I have no objection
to doing it this way.
Does that explain it?
Yes, thanks, but then it still could come in handy to have fE be a full
bitset, so the application gets some eff caps automatically, while
others it has to manually set...
2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
way too overloaded and this functionality is special.
The functionality is special, but someone with CAP_SYS_ADMIN can always
unload the capability module and create the security.capability xattr
using the dummy module.
This argument leads down a rat hole. (As appears to have happened with
the non-modularization LSM thread elsewhere...)
The simple fact is that CAP_SYS_ADMIN is equivalent to every other
capability in the system if it can be used to load any flavor of kernel
module. Arguing that you don't need a capability for something because
you can do it with CAP_SYS_ADMIN is very close to admitting that you
prefer the superuser (uid=0) model.
Well no, it could also just be acknowledging that at some point some
better cap breakup should be attempted, though of course some amount of
these caps can subvert that cap will always be there.
But I'm not actually objecting :) I expect this will be the first of
the patches I whip up.
If we do add this cap, do we want to make it apply to all security.*
xattrs?
I recommend limiting it to just capabilities.
For now, you can leave the other security attributes with the
CAP_SYS_ADMIN (misc) capability. In the original 'POSIX' drafts, there
is a separate notion of advisory and mandatory access control;
leveraging different capabilities to override.
3) The cap_from_disk() interface checking needs some work Most
notably, size must be greater than sizeof(u32) or the very first line
will do something nasty... I'd recommend you use code like this:
[...] cap_from_disk(...)
{
if (size != sizeof(struct vfs_cap_data)) {
[...]
mistake at least once... The future is uncertain, so don't trust it will
look the way you want it to. ;-)
Ok, so you're saying that when we do switch to 64-bit caps or some other
evolution, we switch to completely separate logic based on the
VFS_CAP_REVISION?
Yes.
That seems sane to me.
You might also want to verify that unallocated bits hold the value
'zero'. Its funny what people do when they realize they can silently
store bits in obscure places like this. That really messes up allocating
bits in the future. Add a check that is something like:
if (version ~(VFS_CAP_REVISION_MASK|VFS_CAP_FLAGS_EFFECTIVE)) {
return -EINVAL;
}
I used to do that (except with a stupid loop), but let's say you update
your distro, but the updated kernel has a problem. So you boot into an
older kernel. But the distro update added a new capability. Now
nothing runs with privilege.
Or are you
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
>
>> I don't particularly mind, but can you point out any case where
>> it is an advantage to have the one bit for f'E rather than just
>> drop f'E altogether? Instead of having
>
>> f'I=something
>> f'P=something
>> f'E=off
>
>> we can always just remove the security.capability xattr. Right?
No. Bear in mind that capabilities are all about trusting specific
applications with privilege as opposed to trusting the superuser to not
run dangerous applications.
There are three situations, we'll take them in turn:
- no capabilities (fP=fI=fE=0): this is for applications that are not
intended to operate with privilege. Because of the way the capability
convolution rules work, such a program can't execute with privilege. Period.
- with capabilities (fP and/or fI != 0), but fE=0 (off): this is for
applications that are intended to operate with privilege, but they were
designed to know about capabilities and they manipulate (raise and
lower) capabilities as needed to do the things they do.
- with capabilities, but fE=1 (on): this is a class of applications
loosely called 'legacy'. They can use privilege to operate, but don't
strictly need to know about it. For example, /bin/chown . Such a program
will have fP=0,fI=CAP_CHOWN. Since the administrator sets
fP=0,fI=CAP_CHOWN,fE=1 on the /bin/chown file, any process with
CAP_CHOWN in its inheritable set (pI) can "exec /bin/chown" and have it
do the thing historically reserved for the superuser...
In some future world, the legacy fE bit may become unnecessary because
every application will be rewritten to be careful about exercising
privilege explicitly. In the meantime, the fE bit can be used to drop
the setuid-0 bits from things like ping and traceroute.
>> If there's a case where that does not suffice, then I have no objection
>> to doing it this way.
Does that explain it?
> 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
> whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
> way too overloaded and this functionality is special.
>
>> The functionality is special, but someone with CAP_SYS_ADMIN can always
>> unload the capability module and create the security.capability xattr
>> using the dummy module.
This argument leads down a rat hole. (As appears to have happened with
the non-modularization LSM thread elsewhere...)
The simple fact is that CAP_SYS_ADMIN is equivalent to every other
capability in the system if it can be used to load any flavor of kernel
module. Arguing that you don't need a capability for something because
you can do it with CAP_SYS_ADMIN is very close to admitting that you
prefer the superuser (uid=0) model.
>> If we do add this cap, do we want to make it apply to all security.*
>> xattrs?
I recommend limiting it to just capabilities.
For now, you can leave the other security attributes with the
CAP_SYS_ADMIN ("misc") capability. In the original 'POSIX' drafts, there
is a separate notion of advisory and mandatory access control;
leveraging different capabilities to override.
> 3) The cap_from_disk() interface checking needs some work Most
> notably, size must be greater than sizeof(u32) or the very first line
> will do something nasty... I'd recommend you use code like this:
>
> [...] cap_from_disk(...)
> {
>if (size != sizeof(struct vfs_cap_data)) {
[...]
> mistake at least once... The future is uncertain, so don't trust it will
> look the way you want it to. ;-)
>
>> Ok, so you're saying that when we do switch to 64-bit caps or some other
>> evolution, we switch to completely separate logic based on the
>> VFS_CAP_REVISION?
Yes.
>> That seems sane to me.
You might also want to verify that unallocated bits hold the value
'zero'. Its funny what people do when they realize they can silently
store bits in obscure places like this. That really messes up allocating
bits in the future. Add a check that is something like:
if (version & ~(VFS_CAP_REVISION_MASK|VFS_CAP_FLAGS_EFFECTIVE)) {
return -EINVAL;
}
> 7) This one is subtle, and to my mind not well appreciated. In
> cap_bprm_apply_creds(), the wart of the global 'cap_bset' masking
> permitted bits can lead to problems like the one we saw a few years back
> with sendmail and capabilities. There is an assumption in setting
> permitted (they are called 'forced' in some documents) capabilities on a
> file that the file will execute with at least these. The inheritable
> ones are optional.
>
>> Hmm, changing the behavior of the cap_bset is something that seems to
>> belong in 8), though I see what you're saying, it does affect the
>> behavior of vfs caps.
I'm not really changing the behavior of cap_bset. I'm specifying the
behavior of fP. ;-)
[Your comments on cap_bset and CAP_SETPCAP are exactly where my
ax^H^H^Hscalpel will fall after all this VFS support is stable. But
*that* is a subject for a different thread... aka item 8.]
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
I don't particularly mind, but can you point out any case where
it is an advantage to have the one bit for f'E rather than just
drop f'E altogether? Instead of having
f'I=something
f'P=something
f'E=off
we can always just remove the security.capability xattr. Right?
No. Bear in mind that capabilities are all about trusting specific
applications with privilege as opposed to trusting the superuser to not
run dangerous applications.
There are three situations, we'll take them in turn:
- no capabilities (fP=fI=fE=0): this is for applications that are not
intended to operate with privilege. Because of the way the capability
convolution rules work, such a program can't execute with privilege. Period.
- with capabilities (fP and/or fI != 0), but fE=0 (off): this is for
applications that are intended to operate with privilege, but they were
designed to know about capabilities and they manipulate (raise and
lower) capabilities as needed to do the things they do.
- with capabilities, but fE=1 (on): this is a class of applications
loosely called 'legacy'. They can use privilege to operate, but don't
strictly need to know about it. For example, /bin/chown . Such a program
will have fP=0,fI=CAP_CHOWN. Since the administrator sets
fP=0,fI=CAP_CHOWN,fE=1 on the /bin/chown file, any process with
CAP_CHOWN in its inheritable set (pI) can exec /bin/chown and have it
do the thing historically reserved for the superuser...
In some future world, the legacy fE bit may become unnecessary because
every application will be rewritten to be careful about exercising
privilege explicitly. In the meantime, the fE bit can be used to drop
the setuid-0 bits from things like ping and traceroute.
If there's a case where that does not suffice, then I have no objection
to doing it this way.
Does that explain it?
2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
way too overloaded and this functionality is special.
The functionality is special, but someone with CAP_SYS_ADMIN can always
unload the capability module and create the security.capability xattr
using the dummy module.
This argument leads down a rat hole. (As appears to have happened with
the non-modularization LSM thread elsewhere...)
The simple fact is that CAP_SYS_ADMIN is equivalent to every other
capability in the system if it can be used to load any flavor of kernel
module. Arguing that you don't need a capability for something because
you can do it with CAP_SYS_ADMIN is very close to admitting that you
prefer the superuser (uid=0) model.
If we do add this cap, do we want to make it apply to all security.*
xattrs?
I recommend limiting it to just capabilities.
For now, you can leave the other security attributes with the
CAP_SYS_ADMIN (misc) capability. In the original 'POSIX' drafts, there
is a separate notion of advisory and mandatory access control;
leveraging different capabilities to override.
3) The cap_from_disk() interface checking needs some work Most
notably, size must be greater than sizeof(u32) or the very first line
will do something nasty... I'd recommend you use code like this:
[...] cap_from_disk(...)
{
if (size != sizeof(struct vfs_cap_data)) {
[...]
mistake at least once... The future is uncertain, so don't trust it will
look the way you want it to. ;-)
Ok, so you're saying that when we do switch to 64-bit caps or some other
evolution, we switch to completely separate logic based on the
VFS_CAP_REVISION?
Yes.
That seems sane to me.
You might also want to verify that unallocated bits hold the value
'zero'. Its funny what people do when they realize they can silently
store bits in obscure places like this. That really messes up allocating
bits in the future. Add a check that is something like:
if (version ~(VFS_CAP_REVISION_MASK|VFS_CAP_FLAGS_EFFECTIVE)) {
return -EINVAL;
}
7) This one is subtle, and to my mind not well appreciated. In
cap_bprm_apply_creds(), the wart of the global 'cap_bset' masking
permitted bits can lead to problems like the one we saw a few years back
with sendmail and capabilities. There is an assumption in setting
permitted (they are called 'forced' in some documents) capabilities on a
file that the file will execute with at least these. The inheritable
ones are optional.
Hmm, changing the behavior of the cap_bset is something that seems to
belong in 8), though I see what you're saying, it does affect the
behavior of vfs caps.
I'm not really changing the behavior of cap_bset. I'm specifying the
behavior of fP. ;-)
[Your comments on cap_bset and CAP_SETPCAP are exactly where my
ax^H^H^Hscalpel will fall after all this VFS support is stable. But
*that* is a subject for a different thread... aka item 8.]
So yeah, I think you're right - but the question is whose word do we
Re: implement-file-posix-capabilities.patch
On Sun, 24 Jun 2007, Serge E. Hallyn wrote: > > 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate > > whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is > > way too overloaded and this functionality is special. > > The functionality is special, but someone with CAP_SYS_ADMIN can always > unload the capability module and create the security.capability xattr > using the dummy module. > > If we do add this cap, do we want to make it apply to all security.* > xattrs? The underlying issue here is the notion of security mechanisms which are built as loadable modules. It's not useful for any in-tree users, and introduces several unnecessary problems which then need to be addressed. A better approach would be to make LSM a statically linked interface. This would also allow us to unexport the LSM symbols and reduce the API abuse by third-party modules. - James -- James Morris <[EMAIL PROTECTED]> - 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/
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Serge,
>
> [time passes]
>
> I'm a little better up to speed on all the kernel now. I don't feel that
> I conceptually object so much to this patch-series any more :-)
>
> I do, however, think the patch needs some work:
>
> 1) As previously discussed, fE should be an all or nothing single bit:
>
> How about?:
>
> #define VFS_CAP_REVISION_MASK 0xFF00
> #define VFS_CAP_REVISION 0x0100
>
> #define VFS_CAP_FLAGS_MASK~VFS_CAP_REVISION_MASK
> #define VFS_CAP_FLAGS_EFFECTIVE 0x01
>
> struct vfs_cap_data {
> __u32 magic_etc;
> struct {
> __u32 permitted; /* Little endian */
> __u32 inheritable; /* Little endian */
> } data[1];
> };
I don't particularly mind, but can you point out any case where
it is an advantage to have the one bit for f'E rather than just
drop f'E altogether? Instead of having
f'I=something
f'P=something
f'E=off
we can always just remove the security.capability xattr. Right?
If there's a case where that does not suffice, then I have no objection
to doing it this way.
> 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
> whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
> way too overloaded and this functionality is special.
The functionality is special, but someone with CAP_SYS_ADMIN can always
unload the capability module and create the security.capability xattr
using the dummy module.
If we do add this cap, do we want to make it apply to all security.*
xattrs?
> 3) The cap_from_disk() interface checking needs some work Most
> notably, size must be greater than sizeof(u32) or the very first line
> will do something nasty... I'd recommend you use code like this:
>
> [...] cap_from_disk(...)
> {
>if (size != sizeof(struct vfs_cap_data)) {
> printk(KERN_WARNING "%s: invalid cap size %d for file %s\n",
>__FUNCTION__, size, bprm->filename);
> return -EINVAL;
>}
>
>switch ((version & VFS_CAP_REVISION_MASK)) {
>case VFS_CAP_REVISION:
> bprm->cap_effective = (version & VFS_CAP_FLAGS_EFFECTIVE)
> ? CAP_FULL_SET : CAP_EMPTY_SET;
> bprm->cap_permitted =
> to_cap_t( le32_to_cpu(dcap->data[0].permitted) );
> bprm->cap_inheritable =
> to_cap_t( le32_to_cpu(dcap->data[0].inheritable) );
> return 0;
>default:
> return -EINVAL;
>}
> }
>
> Basically, I don't believe in designing a secure interface to be forward
> compatible - things never work out that way and the legacy you are
> implicitly committing to will haunt you in the future... FWIW I've known
> a few x86 MSR designers over the years and each one has made this
> mistake at least once... The future is uncertain, so don't trust it will
> look the way you want it to. ;-)
Ok, so you're saying that when we do switch to 64-bit caps or some other
evolution, we switch to completely separate logic based on the
VFS_CAP_REVISION?
That seems sane to me.
> 5) I would rename 'set_file_caps' to 'get_file_caps' since this is what
> the function actually does. If you must use 'set' then call the function
> 'set_bprm_caps'.
set_bprm_caps actually sounds best to me.
> 6) I also don't see the value of explicitly zero'ing the capabilities
> (in cap_bprm_set_security()) only to override them elsewhere.
>
> I'd move the 'cap_clear (bprm->cap_...)' code from
> cap_bprm_set_security() into the 'out:' code at the end of
> 'get_file_caps()' (sic). Put rc=0 at the top of the function, and
> replace the return 0; at the top of that function with a 'goto
> clear_out;' then replace the out: code as follows:
>
>out:
>dput(dentry);
>if ((void *)dcaps != (void *))
> kfree(dcaps);
>if (rc) {
>clear_out:
> cap_clear (bprm->cap_inheritable);
> cap_clear (bprm->cap_permitted);
> cap_clear (bprm->cap_effective);
>}
>return rc;
Sounds sane. If it looks less sane when I try to write the patch I'll
get back to you :)
> 7) This one is subtle, and to my mind not well appreciated. In
> cap_bprm_apply_creds(), the wart of the global 'cap_bset' masking
> permitted bits can lead to problems like the one we saw a few years back
> with sendmail and capabilities. There is an assumption in setting
> permitted (they are called 'forced' in some documents) capabilities on a
> file that the file will execute with at least these. The inheritable
> ones are optional.
Hmm, changing the behavior of the cap_bset is something that seems to
belong in 8), though I see what you're saying, it does affect the
behavior of vfs caps.
One gets a cozy feeling from the fact that cap_bset is set to
(~0 & ~~CAP_TO_MASK(CAP_SETPCAP)), but since it's sysctl controllable
that seems like it could present a real
Re: implement-file-posix-capabilities.patch
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
[time passes]
I'm a little better up to speed on all the kernel now. I don't feel that
I conceptually object so much to this patch-series any more :-)
I do, however, think the patch needs some work:
1) As previously discussed, fE should be an all or nothing single bit:
How about?:
#define VFS_CAP_REVISION_MASK 0xFF00
#define VFS_CAP_REVISION 0x0100
#define VFS_CAP_FLAGS_MASK~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x01
struct vfs_cap_data {
__u32 magic_etc;
struct {
__u32 permitted; /* Little endian */
__u32 inheritable; /* Little endian */
} data[1];
};
I don't particularly mind, but can you point out any case where
it is an advantage to have the one bit for f'E rather than just
drop f'E altogether? Instead of having
f'I=something
f'P=something
f'E=off
we can always just remove the security.capability xattr. Right?
If there's a case where that does not suffice, then I have no objection
to doing it this way.
2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
way too overloaded and this functionality is special.
The functionality is special, but someone with CAP_SYS_ADMIN can always
unload the capability module and create the security.capability xattr
using the dummy module.
If we do add this cap, do we want to make it apply to all security.*
xattrs?
3) The cap_from_disk() interface checking needs some work Most
notably, size must be greater than sizeof(u32) or the very first line
will do something nasty... I'd recommend you use code like this:
[...] cap_from_disk(...)
{
if (size != sizeof(struct vfs_cap_data)) {
printk(KERN_WARNING %s: invalid cap size %d for file %s\n,
__FUNCTION__, size, bprm-filename);
return -EINVAL;
}
switch ((version VFS_CAP_REVISION_MASK)) {
case VFS_CAP_REVISION:
bprm-cap_effective = (version VFS_CAP_FLAGS_EFFECTIVE)
? CAP_FULL_SET : CAP_EMPTY_SET;
bprm-cap_permitted =
to_cap_t( le32_to_cpu(dcap-data[0].permitted) );
bprm-cap_inheritable =
to_cap_t( le32_to_cpu(dcap-data[0].inheritable) );
return 0;
default:
return -EINVAL;
}
}
Basically, I don't believe in designing a secure interface to be forward
compatible - things never work out that way and the legacy you are
implicitly committing to will haunt you in the future... FWIW I've known
a few x86 MSR designers over the years and each one has made this
mistake at least once... The future is uncertain, so don't trust it will
look the way you want it to. ;-)
Ok, so you're saying that when we do switch to 64-bit caps or some other
evolution, we switch to completely separate logic based on the
VFS_CAP_REVISION?
That seems sane to me.
5) I would rename 'set_file_caps' to 'get_file_caps' since this is what
the function actually does. If you must use 'set' then call the function
'set_bprm_caps'.
set_bprm_caps actually sounds best to me.
6) I also don't see the value of explicitly zero'ing the capabilities
(in cap_bprm_set_security()) only to override them elsewhere.
I'd move the 'cap_clear (bprm-cap_...)' code from
cap_bprm_set_security() into the 'out:' code at the end of
'get_file_caps()' (sic). Put rc=0 at the top of the function, and
replace the return 0; at the top of that function with a 'goto
clear_out;' then replace the out: code as follows:
out:
dput(dentry);
if ((void *)dcaps != (void *)v1caps)
kfree(dcaps);
if (rc) {
clear_out:
cap_clear (bprm-cap_inheritable);
cap_clear (bprm-cap_permitted);
cap_clear (bprm-cap_effective);
}
return rc;
Sounds sane. If it looks less sane when I try to write the patch I'll
get back to you :)
7) This one is subtle, and to my mind not well appreciated. In
cap_bprm_apply_creds(), the wart of the global 'cap_bset' masking
permitted bits can lead to problems like the one we saw a few years back
with sendmail and capabilities. There is an assumption in setting
permitted (they are called 'forced' in some documents) capabilities on a
file that the file will execute with at least these. The inheritable
ones are optional.
Hmm, changing the behavior of the cap_bset is something that seems to
belong in 8), though I see what you're saying, it does affect the
behavior of vfs caps.
One gets a cozy feeling from the fact that cap_bset is set to
(~0 ~~CAP_TO_MASK(CAP_SETPCAP)), but since it's sysctl controllable
that seems like it could present a real security problem.
So yeah, I think you're right - but the question is whose word do we
take here? The
Re: implement-file-posix-capabilities.patch
On Sun, 24 Jun 2007, Serge E. Hallyn wrote: 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is way too overloaded and this functionality is special. The functionality is special, but someone with CAP_SYS_ADMIN can always unload the capability module and create the security.capability xattr using the dummy module. If we do add this cap, do we want to make it apply to all security.* xattrs? The underlying issue here is the notion of security mechanisms which are built as loadable modules. It's not useful for any in-tree users, and introduces several unnecessary problems which then need to be addressed. A better approach would be to make LSM a statically linked interface. This would also allow us to unexport the LSM symbols and reduce the API abuse by third-party modules. - James -- James Morris [EMAIL PROTECTED] - 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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
[time passes]
I'm a little better up to speed on all the kernel now. I don't feel that
I conceptually object so much to this patch-series any more :-)
I do, however, think the patch needs some work:
1) As previously discussed, fE should be an all or nothing single bit:
How about?:
#define VFS_CAP_REVISION_MASK 0xFF00
#define VFS_CAP_REVISION 0x0100
#define VFS_CAP_FLAGS_MASK~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x01
struct vfs_cap_data {
__u32 magic_etc;
struct {
__u32 permitted; /* Little endian */
__u32 inheritable; /* Little endian */
} data[1];
};
2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
way too overloaded and this functionality is special.
3) The cap_from_disk() interface checking needs some work Most
notably, size must be greater than sizeof(u32) or the very first line
will do something nasty... I'd recommend you use code like this:
[...] cap_from_disk(...)
{
if (size != sizeof(struct vfs_cap_data)) {
printk(KERN_WARNING "%s: invalid cap size %d for file %s\n",
__FUNCTION__, size, bprm->filename);
return -EINVAL;
}
switch ((version & VFS_CAP_REVISION_MASK)) {
case VFS_CAP_REVISION:
bprm->cap_effective = (version & VFS_CAP_FLAGS_EFFECTIVE)
? CAP_FULL_SET : CAP_EMPTY_SET;
bprm->cap_permitted =
to_cap_t( le32_to_cpu(dcap->data[0].permitted) );
bprm->cap_inheritable =
to_cap_t( le32_to_cpu(dcap->data[0].inheritable) );
return 0;
default:
return -EINVAL;
}
}
Basically, I don't believe in designing a secure interface to be forward
compatible - things never work out that way and the legacy you are
implicitly committing to will haunt you in the future... FWIW I've known
a few x86 MSR designers over the years and each one has made this
mistake at least once... The future is uncertain, so don't trust it will
look the way you want it to. ;-)
5) I would rename 'set_file_caps' to 'get_file_caps' since this is what
the function actually does. If you must use 'set' then call the function
'set_bprm_caps'.
6) I also don't see the value of explicitly zero'ing the capabilities
(in cap_bprm_set_security()) only to override them elsewhere.
I'd move the 'cap_clear (bprm->cap_...)' code from
cap_bprm_set_security() into the 'out:' code at the end of
'get_file_caps()' (sic). Put rc=0 at the top of the function, and
replace the return 0; at the top of that function with a 'goto
clear_out;' then replace the out: code as follows:
out:
dput(dentry);
if ((void *)dcaps != (void *))
kfree(dcaps);
if (rc) {
clear_out:
cap_clear (bprm->cap_inheritable);
cap_clear (bprm->cap_permitted);
cap_clear (bprm->cap_effective);
}
return rc;
7) This one is subtle, and to my mind not well appreciated. In
cap_bprm_apply_creds(), the wart of the global 'cap_bset' masking
permitted bits can lead to problems like the one we saw a few years back
with sendmail and capabilities. There is an assumption in setting
permitted (they are called 'forced' in some documents) capabilities on a
file that the file will execute with at least these. The inheritable
ones are optional.
The long and the short of it is there needs to be a check somewhere that:
current->cap_permitted is a superset of file->cap_permitted
That is, what cap_bset takes away, current->cap_inheritable gives back.
If the above is not true, then the executable should fail to execute;
- -EPERM. On the surface I don't see how to do this with the LSM framework
because the relevant function is a 'void' one and can't return an error.
8) There are a number of (massive) cleanups that I would like to see
done, but they are more related to the non-file capabilities support in
the kernel and I won't pollute this present discussion any more with those.
I hope that was helpful. FWIW I did set up a git repostitory on
kernel.org to port my old patches, but in the process of porting them
better understood what you had done. If you do the above I think I'd be
happy to work from that...
Cheers
Andrew
PS. If anyone is touching file with my transmeta email in them, feel
free to replace them with the @kernel.org address.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGfNYwQheEq9QabfIRAgQ2AJ9q3+BgOPlZvTboqEyM3O845xKZOQCcCLQm
zKVfemAw2F5h43rApDXuJ4o=
=OJWn
-END PGP SIGNATURE-
-
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/
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
[time passes]
I'm a little better up to speed on all the kernel now. I don't feel that
I conceptually object so much to this patch-series any more :-)
I do, however, think the patch needs some work:
1) As previously discussed, fE should be an all or nothing single bit:
How about?:
#define VFS_CAP_REVISION_MASK 0xFF00
#define VFS_CAP_REVISION 0x0100
#define VFS_CAP_FLAGS_MASK~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x01
struct vfs_cap_data {
__u32 magic_etc;
struct {
__u32 permitted; /* Little endian */
__u32 inheritable; /* Little endian */
} data[1];
};
2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
way too overloaded and this functionality is special.
3) The cap_from_disk() interface checking needs some work Most
notably, size must be greater than sizeof(u32) or the very first line
will do something nasty... I'd recommend you use code like this:
[...] cap_from_disk(...)
{
if (size != sizeof(struct vfs_cap_data)) {
printk(KERN_WARNING %s: invalid cap size %d for file %s\n,
__FUNCTION__, size, bprm-filename);
return -EINVAL;
}
switch ((version VFS_CAP_REVISION_MASK)) {
case VFS_CAP_REVISION:
bprm-cap_effective = (version VFS_CAP_FLAGS_EFFECTIVE)
? CAP_FULL_SET : CAP_EMPTY_SET;
bprm-cap_permitted =
to_cap_t( le32_to_cpu(dcap-data[0].permitted) );
bprm-cap_inheritable =
to_cap_t( le32_to_cpu(dcap-data[0].inheritable) );
return 0;
default:
return -EINVAL;
}
}
Basically, I don't believe in designing a secure interface to be forward
compatible - things never work out that way and the legacy you are
implicitly committing to will haunt you in the future... FWIW I've known
a few x86 MSR designers over the years and each one has made this
mistake at least once... The future is uncertain, so don't trust it will
look the way you want it to. ;-)
5) I would rename 'set_file_caps' to 'get_file_caps' since this is what
the function actually does. If you must use 'set' then call the function
'set_bprm_caps'.
6) I also don't see the value of explicitly zero'ing the capabilities
(in cap_bprm_set_security()) only to override them elsewhere.
I'd move the 'cap_clear (bprm-cap_...)' code from
cap_bprm_set_security() into the 'out:' code at the end of
'get_file_caps()' (sic). Put rc=0 at the top of the function, and
replace the return 0; at the top of that function with a 'goto
clear_out;' then replace the out: code as follows:
out:
dput(dentry);
if ((void *)dcaps != (void *)v1caps)
kfree(dcaps);
if (rc) {
clear_out:
cap_clear (bprm-cap_inheritable);
cap_clear (bprm-cap_permitted);
cap_clear (bprm-cap_effective);
}
return rc;
7) This one is subtle, and to my mind not well appreciated. In
cap_bprm_apply_creds(), the wart of the global 'cap_bset' masking
permitted bits can lead to problems like the one we saw a few years back
with sendmail and capabilities. There is an assumption in setting
permitted (they are called 'forced' in some documents) capabilities on a
file that the file will execute with at least these. The inheritable
ones are optional.
The long and the short of it is there needs to be a check somewhere that:
current-cap_permitted is a superset of file-cap_permitted
That is, what cap_bset takes away, current-cap_inheritable gives back.
If the above is not true, then the executable should fail to execute;
- -EPERM. On the surface I don't see how to do this with the LSM framework
because the relevant function is a 'void' one and can't return an error.
8) There are a number of (massive) cleanups that I would like to see
done, but they are more related to the non-file capabilities support in
the kernel and I won't pollute this present discussion any more with those.
I hope that was helpful. FWIW I did set up a git repostitory on
kernel.org to port my old patches, but in the process of porting them
better understood what you had done. If you do the above I think I'd be
happy to work from that...
Cheers
Andrew
PS. If anyone is touching file with my transmeta email in them, feel
free to replace them with the @kernel.org address.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGfNYwQheEq9QabfIRAgQ2AJ9q3+BgOPlZvTboqEyM3O845xKZOQCcCLQm
zKVfemAw2F5h43rApDXuJ4o=
=OJWn
-END PGP SIGNATURE-
-
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/
Re: implement-file-posix-capabilities.patch
Quoting Chris Wright ([EMAIL PROTECTED]): > [folks, this is getting much too long-winded to stay a private thread] > > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > Quoting Chris Wright ([EMAIL PROTECTED]): > > > * Andrew Morgan ([EMAIL PROTECTED]) wrote: > > > > I share Casey's view that what's in the kernel now appears to have > > > > evolved because of the absence of filesystem capabilities and not in > > > > preparation for them. I'm not at all clear that they offer any real > > > > improvement over the more macroscopic, but much simpler to understand, > > > > superuser model. > > > > > > Presently they offer next to nothing. From the POV of kernel code, > > > they've added an extremely coarse grained way to check privs for > > > actions (CAP_SYS_ADMIN renders much of this useless for least priv). > > > >From userspace POV, there's basically one well-known program that uses > > > the existing crippled model to drop privs. And from end-users' POV, > > > there's no end of frustrated attempts to make something useful out > > > of it. From a security POV, there's missing functionality (which has > > > been addressed in Andrew's older patches and Serge's current patchset). > > > > I'm sorry I'm not sure what your conclusion is then. Are you saying > > that my patch does add functionality, or arguing that it shouldn't be > > included? > > It does add functionality, it is existing capabilities which are not > particularly useful. Ah, ok. > > > > I think the implementation (the patch) adds support for storing > > > > capabilities in the filesystem. But, I don't believe it is as a step > > > > towards 'POSIX' capability support, but just adding another incrementa > > > > twist to the Linux capability implementation - its hard to reason about > > > > such a thing, in terms of security or otherwise. (Have you thought about > > > > whether LD_LIBRARY_PATH is ignored by capability aware, but non-setuid-0 > > > > programs? To voice one example. There are many system consequences to > > > > this model that will only become apparent when people start to seriously > > > > implement and use it.) > > > > > > The classic argument has been one of administration. Tools know how to > > > search for setuid programs, > > > > Sure, but 'find' plus a 5-line program to check for security.capability > > xattrs will find capability programs, right? > > Yes. I'm not 100% sold on the administration issue, but it is real, and > unfortunately the extra 5-line program isn't a great solution. It might not be :), but surely once people see what the actual administration challenges turn out to be, they/we can write the tools to satisfy those needs? I don't believe they will be insurmountable. You had in the past played with caps quite a bit, do you already have a sense of what kinds of admin problems people will have? > > Are there popular gui's in > > widespread use which depend on programs granting extra privilege doing > > so using setuid? > > > > > and mainline MAC is not adding caps based on > > > security domain during exec, etc. > > > > I don't understand what you're saying - could you explain? Which > > 'mainline MAC', what sort of domains (TE?)? > > mainline MAC meaning basically SELinux. IOW, while LIDS and Apparmor > had/have models for handling capabilities (don't recall if it was grant > or restrict only), SELinux is just now talking about doing something > like this, but nothing is upstream and in wide distribution. > > > > My biggest concern is leaking caps to > > > programs which are meant to be unprivileged. > > > > Would it help if we place CONFIG_SECURITY_FILE_CAPABILITIES under > > CONFIG_EXPERIMENTAl for a bit? > > Would not hurt ;-) Ok, here's a patch on top of 2.6.22-rc4-mm2 to do so, thanks, -serge >From bf1566bb34ed47ffadfe9289ba2f1a85df5dc36f Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Thu, 21 Jun 2007 11:40:23 -0400 Subject: [PATCH 1/1] file capabilities: make file capabilities option EXPERIMENTAL Make file capabilities depend upon CONFIG_EXPERIMENTAL, as few people have used them to date. Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]> --- security/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/security/Kconfig b/security/Kconfig index 7c941d9..ac56c2c 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -81,8 +81,8 @@ config SECURITY_CAPABILITIES If you are unsure how to answer this question, answer Y. config SECURITY_FILE_CAPABILITIES - bool "File POSIX Capabilities" - depends on SECURITY=n || SECURITY_CAPABILITIES!=n + bool "File POSIX Capabilities (EXPERIMENTAL)" + depends on (SECURITY=n || SECURITY_CAPABILITIES!=n) && EXPERIMENTAL default n help This enables filesystem capabilities, allowing you to give -- 1.5.1.1.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]
Re: implement-file-posix-capabilities.patch
Quoting Chris Wright ([EMAIL PROTECTED]): [folks, this is getting much too long-winded to stay a private thread] * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: Quoting Chris Wright ([EMAIL PROTECTED]): * Andrew Morgan ([EMAIL PROTECTED]) wrote: I share Casey's view that what's in the kernel now appears to have evolved because of the absence of filesystem capabilities and not in preparation for them. I'm not at all clear that they offer any real improvement over the more macroscopic, but much simpler to understand, superuser model. Presently they offer next to nothing. From the POV of kernel code, they've added an extremely coarse grained way to check privs for actions (CAP_SYS_ADMIN renders much of this useless for least priv). From userspace POV, there's basically one well-known program that uses the existing crippled model to drop privs. And from end-users' POV, there's no end of frustrated attempts to make something useful out of it. From a security POV, there's missing functionality (which has been addressed in Andrew's older patches and Serge's current patchset). I'm sorry I'm not sure what your conclusion is then. Are you saying that my patch does add functionality, or arguing that it shouldn't be included? It does add functionality, it is existing capabilities which are not particularly useful. Ah, ok. I think the implementation (the patch) adds support for storing capabilities in the filesystem. But, I don't believe it is as a step towards 'POSIX' capability support, but just adding another incrementa twist to the Linux capability implementation - its hard to reason about such a thing, in terms of security or otherwise. (Have you thought about whether LD_LIBRARY_PATH is ignored by capability aware, but non-setuid-0 programs? To voice one example. There are many system consequences to this model that will only become apparent when people start to seriously implement and use it.) The classic argument has been one of administration. Tools know how to search for setuid programs, Sure, but 'find' plus a 5-line program to check for security.capability xattrs will find capability programs, right? Yes. I'm not 100% sold on the administration issue, but it is real, and unfortunately the extra 5-line program isn't a great solution. It might not be :), but surely once people see what the actual administration challenges turn out to be, they/we can write the tools to satisfy those needs? I don't believe they will be insurmountable. You had in the past played with caps quite a bit, do you already have a sense of what kinds of admin problems people will have? Are there popular gui's in widespread use which depend on programs granting extra privilege doing so using setuid? and mainline MAC is not adding caps based on security domain during exec, etc. I don't understand what you're saying - could you explain? Which 'mainline MAC', what sort of domains (TE?)? mainline MAC meaning basically SELinux. IOW, while LIDS and Apparmor had/have models for handling capabilities (don't recall if it was grant or restrict only), SELinux is just now talking about doing something like this, but nothing is upstream and in wide distribution. My biggest concern is leaking caps to programs which are meant to be unprivileged. Would it help if we place CONFIG_SECURITY_FILE_CAPABILITIES under CONFIG_EXPERIMENTAl for a bit? Would not hurt ;-) Ok, here's a patch on top of 2.6.22-rc4-mm2 to do so, thanks, -serge From bf1566bb34ed47ffadfe9289ba2f1a85df5dc36f Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Thu, 21 Jun 2007 11:40:23 -0400 Subject: [PATCH 1/1] file capabilities: make file capabilities option EXPERIMENTAL Make file capabilities depend upon CONFIG_EXPERIMENTAL, as few people have used them to date. Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/security/Kconfig b/security/Kconfig index 7c941d9..ac56c2c 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -81,8 +81,8 @@ config SECURITY_CAPABILITIES If you are unsure how to answer this question, answer Y. config SECURITY_FILE_CAPABILITIES - bool File POSIX Capabilities - depends on SECURITY=n || SECURITY_CAPABILITIES!=n + bool File POSIX Capabilities (EXPERIMENTAL) + depends on (SECURITY=n || SECURITY_CAPABILITIES!=n) EXPERIMENTAL default n help This enables filesystem capabilities, allowing you to give -- 1.5.1.1.GIT - 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/
