-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
which made it into kernel 4.3 recently. And I have to say that I was
shocked on how could such a patch that breaks normal use of capabilities
make it into the kernel.
Usually I have set very own crafted capabilities set to files instead of
having them SUID root. With that, I have a comparable set of inheritable
capabilities set for limited users. That allows me to nearly drop all
SUID binaries and replace it by only giving the processes the
capabilities they need but only if the users are allowed to act with
that capabilities. Especially, and that is important, it inhibit any
leak of rights to any forked process, be it indented or by a security
problem of the binary.
With the patch above, any process that is spawned by such a program will
inherit the raised capabilities if it has no own filecapabilities set.
Even worse, even every user made tool can be target for such
escalations! That drives the benefits in security of capabilities over
SUID ad-absurdum.
Let me add here, that I disagree with Andy Lutomirski about the
usefulness of capability inheritance in kernels before that patch. They
was fully usefull to only allow selective capabilities if both, the
binary and the user was allowed to use it. I never want to have any
capabilities for processes that I did not allow them to have. Even
worse, I never want any capabilities allowed for any shell. It is
horrible to even think about such a possibility!.
> Users with nonzero pA are unlikely to unintentionally leak that
> capability. If they run programs that try to drop privileges, dropping
> privileges will still work.
Even that is naiv. There are only few programs out there that do
actively drop privileges. Most are agnostic about capabilities. But this
crappy patch introduce a need for _every_ tool to drop all capabilities
right after start to stay in a secure system.
So please revert that patch as fast as possible before it does some harm
by getting into some real world systems!
Regards
Klaus Ethgen
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWN6YaAAoJEKZ8CrGAGfasRGwL/2g3XmG3h1rpidmJnUsMlmvf
YdBSSKdgX8U371WANxoGPzmjE9raQX+Ccn713z8csB/Xnh3AuQMvDsRfX9qWhYCy
eDEE3NxaDvlKzZkDDvZk5TFuFI8iHBIndgkYdN6AYg60aUt9GRYEVIZ9AtZ0t2LG
/x9v7ecF0BEmJRK/Hf6uBfmGsh1sisyJzDtkvh4z/P6RUh/96W0sMZTi0MGolfvT
6B8WPWnyOVRHmxwq1/2rExOr4rwyiDhOc+oGHzj+XfIh30pXUZnlom7w0M5cro61
jK/bJbCQJdqgADp3Nuizf6WUCt/adKqwmlAmKD2kFSFOtUG0A32jdhcqLKBO5aWX
5Cm2lub5a7mdM1hSRGDKzmrQ4phQZNqGUHXG2TOiit5IbmcA0AEyy091oB15Rf6x
xnOoe7nIIPsoDlbfMoQq7qPvbIB4gXimoJtKI4+T4AKr068XWfXeswAYc8V1yviJ
o4R6ja52HwEZ/PykLJFmtiEcfYDQQeT2eADj0kN7rQ==
=m53H
-----END PGP SIGNATURE-----
CC'ing patch authors.
On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
> which made it into kernel 4.3 recently. And I have to say that I was
> shocked on how could such a patch that breaks normal use of capabilities
> make it into the kernel.
>
> Usually I have set very own crafted capabilities set to files instead of
> having them SUID root. With that, I have a comparable set of inheritable
> capabilities set for limited users. That allows me to nearly drop all
> SUID binaries and replace it by only giving the processes the
> capabilities they need but only if the users are allowed to act with
> that capabilities. Especially, and that is important, it inhibit any
> leak of rights to any forked process, be it indented or by a security
> problem of the binary.
>
> With the patch above, any process that is spawned by such a program will
> inherit the raised capabilities if it has no own filecapabilities set.
> Even worse, even every user made tool can be target for such
> escalations! That drives the benefits in security of capabilities over
> SUID ad-absurdum.
>
> Let me add here, that I disagree with Andy Lutomirski about the
> usefulness of capability inheritance in kernels before that patch. They
> was fully usefull to only allow selective capabilities if both, the
> binary and the user was allowed to use it. I never want to have any
> capabilities for processes that I did not allow them to have. Even
> worse, I never want any capabilities allowed for any shell. It is
> horrible to even think about such a possibility!.
>
>> Users with nonzero pA are unlikely to unintentionally leak that
>> capability. If they run programs that try to drop privileges, dropping
>> privileges will still work.
>
> Even that is naiv. There are only few programs out there that do
> actively drop privileges. Most are agnostic about capabilities. But this
> crappy patch introduce a need for _every_ tool to drop all capabilities
> right after start to stay in a secure system.
>
> So please revert that patch as fast as possible before it does some harm
> by getting into some real world systems!
>
> Regards
> Klaus Ethgen
> - --
> Klaus Ethgen http://www.ethgen.ch/
> pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJWN6YaAAoJEKZ8CrGAGfasRGwL/2g3XmG3h1rpidmJnUsMlmvf
> YdBSSKdgX8U371WANxoGPzmjE9raQX+Ccn713z8csB/Xnh3AuQMvDsRfX9qWhYCy
> eDEE3NxaDvlKzZkDDvZk5TFuFI8iHBIndgkYdN6AYg60aUt9GRYEVIZ9AtZ0t2LG
> /x9v7ecF0BEmJRK/Hf6uBfmGsh1sisyJzDtkvh4z/P6RUh/96W0sMZTi0MGolfvT
> 6B8WPWnyOVRHmxwq1/2rExOr4rwyiDhOc+oGHzj+XfIh30pXUZnlom7w0M5cro61
> jK/bJbCQJdqgADp3Nuizf6WUCt/adKqwmlAmKD2kFSFOtUG0A32jdhcqLKBO5aWX
> 5Cm2lub5a7mdM1hSRGDKzmrQ4phQZNqGUHXG2TOiit5IbmcA0AEyy091oB15Rf6x
> xnOoe7nIIPsoDlbfMoQq7qPvbIB4gXimoJtKI4+T4AKr068XWfXeswAYc8V1yviJ
> o4R6ja52HwEZ/PykLJFmtiEcfYDQQeT2eADj0kN7rQ==
> =m53H
> -----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/
--
Thanks,
//richard
On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger
<[email protected]> wrote:
> CC'ing patch authors.
>
> On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <[email protected]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Hi,
>>
>> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
>> which made it into kernel 4.3 recently. And I have to say that I was
>> shocked on how could such a patch that breaks normal use of capabilities
>> make it into the kernel.
>>
>> Usually I have set very own crafted capabilities set to files instead of
>> having them SUID root. With that, I have a comparable set of inheritable
>> capabilities set for limited users. That allows me to nearly drop all
>> SUID binaries and replace it by only giving the processes the
>> capabilities they need but only if the users are allowed to act with
>> that capabilities. Especially, and that is important, it inhibit any
>> leak of rights to any forked process, be it indented or by a security
>> problem of the binary.
>>
>> With the patch above, any process that is spawned by such a program will
>> inherit the raised capabilities if it has no own filecapabilities set.
>> Even worse, even every user made tool can be target for such
>> escalations! That drives the benefits in security of capabilities over
>> SUID ad-absurdum.
Can you describe what it is that you think changed in 4.3 that breaks
anything? The behavior of inheritable capabilities shouldn't have
changed.
>>
>> Let me add here, that I disagree with Andy Lutomirski about the
>> usefulness of capability inheritance in kernels before that patch. They
>> was fully usefull to only allow selective capabilities if both, the
>> binary and the user was allowed to use it. I never want to have any
>> capabilities for processes that I did not allow them to have. Even
>> worse, I never want any capabilities allowed for any shell. It is
>> horrible to even think about such a possibility!.
>>
>>> Users with nonzero pA are unlikely to unintentionally leak that
>>> capability. If they run programs that try to drop privileges, dropping
>>> privileges will still work.
>>
>> Even that is naiv. There are only few programs out there that do
>> actively drop privileges. Most are agnostic about capabilities. But this
>> crappy patch introduce a need for _every_ tool to drop all capabilities
>> right after start to stay in a secure system.
>>
I don't know what you mean. Concrete examples are welcome.
--Andy
On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger
<[email protected]> wrote:
>>
>> With the patch above, any process that is spawned by such a program will
>> inherit the raised capabilities if it has no own filecapabilities set.
Do you actually have a real example of this?
The ambient capabilities stay empty unless you explicitly raise them.
So your old workflow shouldn't actually have any change in it at all.
And if your old workflow gave a capability to something you don't
trust, and that then decides to now uses the ambient capabilities,
what does that change? It had the capability already.
So please explain what it is you actually object to. With actual real issues.
If behavior actually changed of existing setups, then that would be a
bug, and yes, it should be fixed. The new ambient capabilities should
only matter when you choose to use them.
Linus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
Am Mo den 2. Nov 2015 um 19:50 schrieb Andy Lutomirski:
> >> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
> >> which made it into kernel 4.3 recently. And I have to say that I was
> >> shocked on how could such a patch that breaks normal use of capabilities
> >> make it into the kernel.
> >>
> >> Usually I have set very own crafted capabilities set to files instead of
> >> having them SUID root. With that, I have a comparable set of inheritable
> >> capabilities set for limited users. That allows me to nearly drop all
> >> SUID binaries and replace it by only giving the processes the
> >> capabilities they need but only if the users are allowed to act with
> >> that capabilities. Especially, and that is important, it inhibit any
> >> leak of rights to any forked process, be it indented or by a security
> >> problem of the binary.
> >>
> >> With the patch above, any process that is spawned by such a program will
> >> inherit the raised capabilities if it has no own filecapabilities set.
> >> Even worse, even every user made tool can be target for such
> >> escalations! That drives the benefits in security of capabilities over
> >> SUID ad-absurdum.
>
> Can you describe what it is that you think changed in 4.3 that breaks
> anything? The behavior of inheritable capabilities shouldn't have
> changed.
Well, the think that changed is that the ambient capabilities can be set
by any process if the pI and pE are matching for a process. But then,
that capabilities are inherited via execve to even programs that don't
have any capability setting. That allows every subprocess to (mis-)use
it.
> >> Let me add here, that I disagree with Andy Lutomirski about the
> >> usefulness of capability inheritance in kernels before that patch. They
> >> was fully usefull to only allow selective capabilities if both, the
> >> binary and the user was allowed to use it. I never want to have any
> >> capabilities for processes that I did not allow them to have. Even
> >> worse, I never want any capabilities allowed for any shell. It is
> >> horrible to even think about such a possibility!.
> >>
> >>> Users with nonzero pA are unlikely to unintentionally leak that
> >>> capability. If they run programs that try to drop privileges, dropping
> >>> privileges will still work.
> >>
> >> Even that is naiv. There are only few programs out there that do
> >> actively drop privileges. Most are agnostic about capabilities. But this
> >> crappy patch introduce a need for _every_ tool to drop all capabilities
> >> right after start to stay in a secure system.
> >>
>
> I don't know what you mean. Concrete examples are welcome.
Am Mo den 2. Nov 2015 um 19:52 schrieb Linus Torvalds:
> >> With the patch above, any process that is spawned by such a program will
> >> inherit the raised capabilities if it has no own filecapabilities set.
>
> Do you actually have a real example of this?
Very simple example:
~> getcap =mount
/bin/mount = cap_dac_override,cap_sys_admin+ei
~> ls -l =mount
- -rwxr-xr-x 1 root root 40000 Sep 17 15:55 /bin/mount
~> getpcaps $$
Capabilities for `5509': = cap_dac_override,cap_net_raw,cap_sys_rawio,cap_sys_admin+i
What allows me to use mount for mounting shares with user flag without
the need of having a SUID mount. Nice and with a good security level.
Even if the binary has some flaw that allows to exec some unrelated
stuff, there is no harm as after execve, all capabilities are set to 0.
With the alternative approach of having /bin/mount SUID root (as it is
normally), root rights would spread to unrelated tools in such a case.
With pA set (what can be even done in mount itself), the security
problem would be the same as havin mount SUID root.
> The ambient capabilities stay empty unless you explicitly raise them.
> So your old workflow shouldn't actually have any change in it at all.
Ok, As I understand, that pA has to be set explicitly but that doesn't
prevent such problems. For example if someone has managed to break into
my account (in the example above), he can set it himself.
> And if your old workflow gave a capability to something you don't
> trust, and that then decides to now uses the ambient capabilities,
> what does that change? It had the capability already.
Well, not really. With the former approach, the capabilities in pI can
only be used with a specific tool that the admin allowed to inherit.
With pA, every tool can inherit that.
And please ask if I described something not understandable as my main
language is not english. I even might be wrong in understanding the pA.
but I don't think so currently.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWN7Z5AAoJEKZ8CrGAGfasHPcL/jmGC8tSMcxsSLnSB89rxEJf
CaWVwxw+zlhSzaXgLRoip7VaXFMnKEjOfigQ7gehKAqg1lu4aIDmEznHKbGq20Eo
o8FcXV7uqUlicEhmxLunYIjQeFWFip7JPvl1retbvOVsa1xqXVXXPOUZID+2e63S
DbKG1lG4jRGVatW6xjHjOY56AHN0hErnG1g3ONBAz9Ri5QwfxC0UhVlopfSYy13x
M20raMn0VedkJM4dbpOjGskakMij/5OmlY/t3tBiLBcFXS4JzQzkpYw2VJagLzfZ
9DDGIHA7+qTBWBDdy6ZEnR3QTbOozMUj0WBXa9dOukzLm+BtP6ik8v8DAdbdtJmx
6jn7WdMMXs4FpvmvT3y3MYeRm4Rn3qJNZTMe6b77RryzxLf5CIMTYW1rSr9bCRwp
te6bA7IKmGoKbD2Ge4n5PqFVpoVVVqZN0SPiW2dO/cDQ7WM+hb6yEeeYdBlO1gF4
Hw3oPeCLkm0+6R//dqeq1Q6mtIgYxL45Nxlvh4uhpg==
=qWwm
-----END PGP SIGNATURE-----
On Mon, Nov 2, 2015 at 11:16 AM, Klaus Ethgen <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> Am Mo den 2. Nov 2015 um 19:50 schrieb Andy Lutomirski:
>> >> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
>> >> which made it into kernel 4.3 recently. And I have to say that I was
>> >> shocked on how could such a patch that breaks normal use of capabilities
>> >> make it into the kernel.
>> >>
>> >> Usually I have set very own crafted capabilities set to files instead of
>> >> having them SUID root. With that, I have a comparable set of inheritable
>> >> capabilities set for limited users. That allows me to nearly drop all
>> >> SUID binaries and replace it by only giving the processes the
>> >> capabilities they need but only if the users are allowed to act with
>> >> that capabilities. Especially, and that is important, it inhibit any
>> >> leak of rights to any forked process, be it indented or by a security
>> >> problem of the binary.
>> >>
>> >> With the patch above, any process that is spawned by such a program will
>> >> inherit the raised capabilities if it has no own filecapabilities set.
>> >> Even worse, even every user made tool can be target for such
>> >> escalations! That drives the benefits in security of capabilities over
>> >> SUID ad-absurdum.
>>
>> Can you describe what it is that you think changed in 4.3 that breaks
>> anything? The behavior of inheritable capabilities shouldn't have
>> changed.
>
> Well, the think that changed is that the ambient capabilities can be set
> by any process if the pI and pE are matching for a process. But then,
> that capabilities are inherited via execve to even programs that don't
> have any capability setting. That allows every subprocess to (mis-)use
> it.
That's true. I don't see why it's a problem, given that the parent
can already use or mis-use it however it wants, and the child won't
get the capability without explicit action by the parent.
>
>> >> Let me add here, that I disagree with Andy Lutomirski about the
>> >> usefulness of capability inheritance in kernels before that patch. They
>> >> was fully usefull to only allow selective capabilities if both, the
>> >> binary and the user was allowed to use it. I never want to have any
>> >> capabilities for processes that I did not allow them to have. Even
>> >> worse, I never want any capabilities allowed for any shell. It is
>> >> horrible to even think about such a possibility!.
>> >>
>> >>> Users with nonzero pA are unlikely to unintentionally leak that
>> >>> capability. If they run programs that try to drop privileges, dropping
>> >>> privileges will still work.
>> >>
>> >> Even that is naiv. There are only few programs out there that do
>> >> actively drop privileges. Most are agnostic about capabilities. But this
>> >> crappy patch introduce a need for _every_ tool to drop all capabilities
>> >> right after start to stay in a secure system.
>> >>
>>
>> I don't know what you mean. Concrete examples are welcome.
>
> Am Mo den 2. Nov 2015 um 19:52 schrieb Linus Torvalds:
>> >> With the patch above, any process that is spawned by such a program will
>> >> inherit the raised capabilities if it has no own filecapabilities set.
>>
>> Do you actually have a real example of this?
>
> Very simple example:
> ~> getcap =mount
> /bin/mount = cap_dac_override,cap_sys_admin+ei
> ~> ls -l =mount
> - -rwxr-xr-x 1 root root 40000 Sep 17 15:55 /bin/mount
> ~> getpcaps $$
> Capabilities for `5509': = cap_dac_override,cap_net_raw,cap_sys_rawio,cap_sys_admin+i
>
> What allows me to use mount for mounting shares with user flag without
> the need of having a SUID mount. Nice and with a good security level.
> Even if the binary has some flaw that allows to exec some unrelated
> stuff, there is no harm as after execve, all capabilities are set to 0.
> With the alternative approach of having /bin/mount SUID root (as it is
> normally), root rights would spread to unrelated tools in such a case.
That all sounds fine, except that, if you find a security flaw (in
mount of all things -- mount really shouldn't be exposed to untrusted
input in the first place, and if you find a flaw that lets you coerce
mount into execing unrelated things, you can probably also coerce
mount into acting directly on your behalf, but that's irrelevant
here.)
>
> With pA set (what can be even done in mount itself), the security
> problem would be the same as havin mount SUID root.
No, the security problem would be the same as if you compromised
whatever set pA in the first place. In your example, that process (a)
doesn't actually exist and (b) wouldn't have full root rights anyway.
>
> Well, not really. With the former approach, the capabilities in pI can
> only be used with a specific tool that the admin allowed to inherit.
> With pA, every tool can inherit that.
>
> And please ask if I described something not understandable as my main
> language is not english. I even might be wrong in understanding the pA.
> but I don't think so currently.
If your mount binary used prctl to set CAP_SYS_MOUNT in pA, then its
children would have CAP_SYS_MOUNT. Similarly, if your mount binary
used, say, dlopen(), then the shared library would have CAP_SYS_MOUNT
regardless of what the kernel did.
So I still don't see the problem.
--Andy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
sorry for the delay.
Am Mo den 2. Nov 2015 um 20:45 schrieb Andy Lutomirski:
> > Well, the think that changed is that the ambient capabilities can be set
> > by any process if the pI and pE are matching for a process. But then,
> > that capabilities are inherited via execve to even programs that don't
> > have any capability setting. That allows every subprocess to (mis-)use
> > it.
>
> That's true. I don't see why it's a problem, given that the parent
> can already use or mis-use it however it wants, and the child won't
> get the capability without explicit action by the parent.
Well the parent can but usually is not aware of to what it gives this
ambient capabilities to.
Exactly here is the point. There are many applications out there that
needs to be SUID root. Many of them only cause the developer has
something inside like "if getuid() != 0". So in future I suspect many of
such tools that even don't need to give capabilities to childs, are
setting all available capabilities in ambient capabilities before
starting do do something.
With the present way, that was no problem (for OSS). You take away the
SUID, set the capabilities and if the tool complains about not being
root, look into the code and remove that stupid thing. With ambient
capabilities, no one will see that the tool is doing such stupid thing
as setting all capabilities unless some trouble is seen.
And I don't see that as hypothetical. I know many developer who are
misusing sudo as it is introduced by ubuntu by doing:
"sudo less /etc/hosts"
"sudo cd /bla"
"sudo ls"
and so on. Do you really expect such developer being sensitive to use
capabilities carefully? I don't. With the capabilities until now there
was a great tool for the admin to limit damage that can be done with
SUID by replacing it with proper capabilities. Now, with the new ambient
capabilities, that is again leveled. Now the admin looses many control
over what applications are allowed to do.
I know that distributions do not use capabilities at all. But admins
does; at least the ones who cares.
> >> Do you actually have a real example of this?
> >
> > Very simple example:
> > ~> getcap =mount
> > /bin/mount = cap_dac_override,cap_sys_admin+ei
> > ~> ls -l =mount
> > - -rwxr-xr-x 1 root root 40000 Sep 17 15:55 /bin/mount
> > ~> getpcaps $$
> > Capabilities for `5509': = cap_dac_override,cap_net_raw,cap_sys_rawio,cap_sys_admin+i
> >
> > What allows me to use mount for mounting shares with user flag without
> > the need of having a SUID mount. Nice and with a good security level.
> > Even if the binary has some flaw that allows to exec some unrelated
> > stuff, there is no harm as after execve, all capabilities are set to 0.
> > With the alternative approach of having /bin/mount SUID root (as it is
> > normally), root rights would spread to unrelated tools in such a case.
>
> That all sounds fine, except that, if you find a security flaw (in
> mount of all things -- mount really shouldn't be exposed to untrusted
> input in the first place, and if you find a flaw that lets you coerce
> mount into execing unrelated things, you can probably also coerce
> mount into acting directly on your behalf, but that's irrelevant
> here.)
Well, see above. I do not expect mount developer are that stupid. But
examples are fping or pmount.
> > With pA set (what can be even done in mount itself), the security
> > problem would be the same as havin mount SUID root.
>
> No, the security problem would be the same as if you compromised
> whatever set pA in the first place. In your example, that process (a)
> doesn't actually exist and (b) wouldn't have full root rights anyway.
Well, yes, not fully the same.
> > Well, not really. With the former approach, the capabilities in pI can
> > only be used with a specific tool that the admin allowed to inherit.
> > With pA, every tool can inherit that.
> >
> > And please ask if I described something not understandable as my main
> > language is not english. I even might be wrong in understanding the pA.
> > but I don't think so currently.
>
> If your mount binary used prctl to set CAP_SYS_MOUNT in pA, then its
> children would have CAP_SYS_MOUNT. Similarly, if your mount binary
> used, say, dlopen(), then the shared library would have CAP_SYS_MOUNT
> regardless of what the kernel did.
Yes, there is no solution for libraries. I have to admit that I was not
aware of it. But the solution could not be to level the problem to all
binaries. The solution would be to /maybe/ find a way for that too.
Although I do not know if that would be a good idea.
> So I still don't see the problem.
I hope I was able to show the problem above.
Nevertheless, I see that there are two usecases for capabilities. One to
remove SUID at all and set several capabilities explicitly as I do and
second the usecase you described in the commit.
But even your use case has oversees some thinks. It might be ok to
spread capabilities to clear defined processes that are aware of having
such capabilities. But at the latest when a shell is involved that might
proceed many initialisation scripts, the possible damage is
incalculable.
I can live with that ambient capabilities if it is selectable while
compiling the kernel (even then, distribution kernels might be
vulnerable). But overall it is a nightmare, I think.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWOy1EAAoJEKZ8CrGAGfas9BgL/2jPL1EAI9PCnyRuqualPV4N
yYiw2eYyYma8p/gAiU90KhGmz9e4EUo/vLsaEl/pw1Tax5xkpzZncxa/LRXD7Qs6
o+/svhBG7ANlwnRqx5E71kTSPe5UDvsmn1DdOcLdN4x0jedxED6CKzO5QB7f5nxo
W9TvlPLCdeuW3dD78AaoSTNS+kleeAlko3Dq+EPYeQPgBdTtCNwbCKIiDympEj9g
MUGGALo6mH4RLhxgtQ7UKnsVZFCXV79YPXg3qtj/fdiuAbrKMsm0HnCz0/IxMydD
n+tFzwBh7hw0AKgKkvyFeSkvqGgQN0uQcUiwWvIIcGNrPJ2nNVSABhjM3SL7b5Up
F2nZesFJtdFLqsqzmIYu1W3+5yOwJ2Khicje3y6tU6Yehu3BDQsPPacwZYO05YLT
xCSQAIvINUigcCV2dIfZRDGU3ekXpRFhlDNVFfs38wtaHkuWTawnrWkrMQ8TqXBH
QJr63liAxlaj/5SFBmU0sDnR/fFYXIFlu9yVK7b0xw==
=A5kj
-----END PGP SIGNATURE-----
On Thu, Nov 05, 2015 at 11:19:54AM +0100, Klaus Ethgen wrote:
> Hi,
>
> sorry for the delay.
>
> Am Mo den 2. Nov 2015 um 20:45 schrieb Andy Lutomirski:
> > > Well, the think that changed is that the ambient capabilities can be set
> > > by any process if the pI and pE are matching for a process. But then,
> > > that capabilities are inherited via execve to even programs that don't
> > > have any capability setting. That allows every subprocess to (mis-)use
> > > it.
> >
> > That's true. I don't see why it's a problem, given that the parent
> > can already use or mis-use it however it wants, and the child won't
> > get the capability without explicit action by the parent.
>
> Well the parent can but usually is not aware of to what it gives this
> ambient capabilities to.
If it sets ambient caps, then it is exactly agreeing to not be aware
what it's giving ambient caps to.
Maybe the capabilities manpage updates need to be more strongly slanted
toward "if you *can* use pI|fI then you really should do so".
> Exactly here is the point. There are many applications out there that
> needs to be SUID root. Many of them only cause the developer has
> something inside like "if getuid() != 0". So in future I suspect many of
> such tools that even don't need to give capabilities to childs, are
> setting all available capabilities in ambient capabilities before
> starting do do something.
Well, maybe what's really needed is a capabilities project that works with
any upstreams wanting to support a capabilities-only mode to help them
do things the right way. I'd happily help out with that.
> With the present way, that was no problem (for OSS). You take away the
> SUID, set the capabilities and if the tool complains about not being
> root, look into the code and remove that stupid thing. With ambient
> capabilities, no one will see that the tool is doing such stupid thing
> as setting all capabilities unless some trouble is seen.
>
> And I don't see that as hypothetical. I know many developer who are
> misusing sudo as it is introduced by ubuntu by doing:
> "sudo less /etc/hosts"
> "sudo cd /bla"
> "sudo ls"
>
> and so on. Do you really expect such developer being sensitive to use
> capabilities carefully? I don't. With the capabilities until now there
> was a great tool for the admin to limit damage that can be done with
> SUID by replacing it with proper capabilities. Now, with the new ambient
I think if you follow your idea to its logical conclusions, you end
up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
I strongly support people working towards that.
-serge
On Thu, Nov 5, 2015 at 2:19 AM, Klaus Ethgen <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> sorry for the delay.
>
> Am Mo den 2. Nov 2015 um 20:45 schrieb Andy Lutomirski:
>> > Well, the think that changed is that the ambient capabilities can be set
>> > by any process if the pI and pE are matching for a process. But then,
>> > that capabilities are inherited via execve to even programs that don't
>> > have any capability setting. That allows every subprocess to (mis-)use
>> > it.
>>
>> That's true. I don't see why it's a problem, given that the parent
>> can already use or mis-use it however it wants, and the child won't
>> get the capability without explicit action by the parent.
>
> Well the parent can but usually is not aware of to what it gives this
> ambient capabilities to.
>
> Exactly here is the point. There are many applications out there that
> needs to be SUID root. Many of them only cause the developer has
> something inside like "if getuid() != 0". So in future I suspect many of
> such tools that even don't need to give capabilities to childs, are
> setting all available capabilities in ambient capabilities before
> starting do do something.
>
> With the present way, that was no problem (for OSS). You take away the
> SUID, set the capabilities and if the tool complains about not being
> root, look into the code and remove that stupid thing. With ambient
> capabilities, no one will see that the tool is doing such stupid thing
> as setting all capabilities unless some trouble is seen.
SUID is, always has been, and always will be a minefield. People
writing SUID programs need to do it right. When the kernel adds a new
API, doing it right includes not adding a buggy call to the API.
The ambient capability code explicitly zeros pA when running a SUID
binary to avoid problems in which a SUID binary has unexpected ambient
capabilities.
IMO the right long term solution is to just stop using SUID and to
stop using any other mechanism that grants new privileges of any sort
when execve is called. (Windows already works like that, and it's
never been a problem.) When you can boot a distro with no_new_privs
set everywhere (including init) and everything works, then I'll think
we've made considerable progress.
In the mean time, developers of SUID and similar programs (including
anything with file caps and a whole bunch of stuff under SELinux, etc)
need to be very careful. Ambient capabilities don't change that at
all.
--Andy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Serge,
Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> I think if you follow your idea to its logical conclusions, you end
> up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
That I did miss out and seems to be the solution for the problem. So
adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
gets other caps should solve it?
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWO48BAAoJEKZ8CrGAGfasXuML/3a9mYfFg36IW7/OsHpo319P
OSVobV+yobXpou+83BupAI9WYSGzlo35yMdzOTJ0ryEex0CPl/f0HoKQdGRNy+Aj
N5JkTzHGhGHi3j1h+UQqX0qUGrIIdvuEBemeeC+Dq4uMwwJihZQKKVPC/DDJOez8
3YU5PVkcp+4yvMsRLZ1kBcME5m4g5uOI6VPYTnE9ymKKuBDX/XhPKKanG8LL7xm0
qdLy7vj1gOdy828nJfgaEjjYvhYqKU10gfnLQ3Xwws5qtcbitCY9AdAllZri23U5
hXzfMyhYu2GLCwd5plTe4A0u0aCDb8/UtYHXjE32CUgsiqqUulyiDvLHa/kmMBvu
RltvZfArUrE+iDdGtAffsI1a6r6u0816XgAP2ybPBSG+KlNin6qHxNK53rJW1xoq
8BvKvS90/XOzN8/n6AmjfmEqFqGzCWgnzT/vD7NUBHRyUdV+weM6Y1QH5XJ8z6w0
8XftXA0hM9ODo2sIpaXRJdiUJecRwen7X8kbs+61cA==
=QOlH
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
Am Do den 5. Nov 2015 um 17:19 schrieb Andy Lutomirski:
> > With the present way, that was no problem (for OSS). You take away the
> > SUID, set the capabilities and if the tool complains about not being
> > root, look into the code and remove that stupid thing. With ambient
> > capabilities, no one will see that the tool is doing such stupid thing
> > as setting all capabilities unless some trouble is seen.
>
> SUID is, always has been, and always will be a minefield. People
> writing SUID programs need to do it right. When the kernel adds a new
> API, doing it right includes not adding a buggy call to the API.
Thats right. But real world is not optimal.
> The ambient capability code explicitly zeros pA when running a SUID
> binary to avoid problems in which a SUID binary has unexpected ambient
> capabilities.
That is not the point. I do not talk about combining SUID and
capabilities. I even seen that it was implemented that way. I talk about
taking away rights from tools that don't need it.
> IMO the right long term solution is to just stop using SUID and to
> stop using any other mechanism that grants new privileges of any sort
> when execve is called.
Right. That is my intention.
> When you can boot a distro with no_new_privs
> set everywhere (including init) and everything works, then I'll think
> we've made considerable progress.
That might be a longer way to go. I also don't think it it fully doable.
You do always need some applications having special rights. But I like
to pick exactly that rights instead using sudo or SUID.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWO5BzAAoJEKZ8CrGAGfas948L/jde8spo8N+vo+jqVSjRNIsV
M1gHTJ4cahDvKhlK6z2a/5kQSINWP94Ir4LSNh+Qyvvq1ZIDBvVWIgadf4zf7TEf
QfbgKFcdbJaXhWKjdgIaT8LTjRzvyqHGD9F8hoSAYI+zvjOJP3FpXi+1u4QNVcO6
ZiV1Ss+8hUGy44Y2If0yMwYe/Z88elqMOPGHJhqeq44unWG0ZFek5R2xOg2g9qed
MMSz49BLarg0TI9tMO7uwkMXfmhKDh3L0Tdwr6xANwPuaBe5qnFVpQpJ/T/AESv7
uTtzDEjJwN9ZBZra8Zc/Xp02ELoMigAtEWprkl78dEmtKUJnej3MP9xivc6EtKAK
zKunFCmltjwVAtwdggBN+XuJofqltFt0FZpyfX3AwjNrW5ltkXbA/tNL0zoQalqX
+NoFmdEWdi5PcMdxKNoZp7jwrSYG7UN8KDe7ZsSGqrV6iH+pd1KWNog8LOdU3t+W
IfbKdHqVQkIKyYz2R9Dd/o2XnUYpymE75SsZu+6Yhw==
=ffr7
-----END PGP SIGNATURE-----
On Thu, Nov 05, 2015 at 06:17:01PM +0100, Klaus Ethgen wrote:
> Hi Serge,
>
> Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> > I think if you follow your idea to its logical conclusions, you end
> > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
>
> That I did miss out and seems to be the solution for the problem. So
> adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
> gets other caps should solve it?
No that doesn't work, you have to use prctl to set those bits. If you
can get your system to be fully rootless, you can have init or initramfs
do this for you. It'll mean that root and setuid-root binaries have no
automatic privileges beside owning host (proc/sys) files.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Do den 5. Nov 2015 um 18:34 schrieb Serge E. Hallyn:
> > Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> > > I think if you follow your idea to its logical conclusions, you end
> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
> >
> > That I did miss out and seems to be the solution for the problem. So
> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
> > gets other caps should solve it?
>
> No that doesn't work, you have to use prctl to set those bits. If you
> can get your system to be fully rootless, you can have init or initramfs
> do this for you. It'll mean that root and setuid-root binaries have no
> automatic privileges beside owning host (proc/sys) files.
So this is not helping much. But for me it is at least an idea to how to
have abient capabilities _and_ full control for admin. It would be an
un-capability but at least would allow the admin to change the
behaviour.
Another one, that would be much better would be something like
cap_ambient_cap capability to explicitly allow the use of ambient
capabilities.
I have to say that I do not know much about prctl. Just reading the man
page currently. But this seems to be about the second way of taking away
rights from UID 0 instead of explicitly giving rights to selective
binaries.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWO5ZiAAoJEKZ8CrGAGfasxrYMALQUBljC4ZECnt8C+kjADz+p
Myqlotr5LZ70+UdOGAnd6ldDyomFKoQZB+IHOm8NIqx+HH8IivLPUVHePyJt7Zlj
t1fgjlYRlDx5Zourbw8eGW/diQF8FBPF+JKG08XHqh25DiLTijevgrC7TnavQuQm
RQaYqnVyPCBaEMUqE4iIaJ7hz/GY6hPX/hQlBU5z26Z/0QLa/DNQwyP0RJWoGp2q
rzCgU0K1pemtoik0HSEdm3li9rFicWBpJsz+5mSsJUx01q30zMzBCHan/IOaPseZ
476+OWY/AGWtA4qpcC4MLAqfC2atYkVZ2/xiEarRdl71SAepV3n4ZPInIsJZ1/3k
mUs/EJ1pBMKkrcU9Nry9Hra+uMl77Gin8eG+5RE5B2IdeyKGEr1lCRVe4Dd27M0t
H3hy6WhB4lFg/k2TWZK5Haz/6Nn2chSPntiOWnyw+vN7M1q6yiiIo82GI1Du0T0W
vhwgISmEqtAa8CAaSZQuW6VpJ1Z9ztN5+qnhE6mzKg==
=T9bn
-----END PGP SIGNATURE-----
On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Do den 5. Nov 2015 um 18:34 schrieb Serge E. Hallyn:
>> > Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
>> > > I think if you follow your idea to its logical conclusions, you end
>> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
>> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
>> >
>> > That I did miss out and seems to be the solution for the problem. So
>> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
>> > gets other caps should solve it?
>>
>> No that doesn't work, you have to use prctl to set those bits. If you
>> can get your system to be fully rootless, you can have init or initramfs
>> do this for you. It'll mean that root and setuid-root binaries have no
>> automatic privileges beside owning host (proc/sys) files.
>
> So this is not helping much. But for me it is at least an idea to how to
> have abient capabilities _and_ full control for admin. It would be an
> un-capability but at least would allow the admin to change the
> behaviour.
>
> Another one, that would be much better would be something like
> cap_ambient_cap capability to explicitly allow the use of ambient
> capabilities.
>
> I have to say that I do not know much about prctl. Just reading the man
> page currently. But this seems to be about the second way of taking away
> rights from UID 0 instead of explicitly giving rights to selective
> binaries.
OK, everyone, take a deep breath please.
Somewhere very high up on my personal list of generally applicable
security advice: do not turn security knobs for the warm fully
feelings. Let me repeat that in all caps: DO NOT TURN SECURITY KNOBS
FOR THE WARM FUZZY FEELINGS.
When a whole bunch of us designed and iterated on how ambient caps
would work, we were very careful that they would *not* break
pre-existing assumptions that SUID programs could make. Securebits
are very different: they very much do break pre-existing assumptions.
See, for example, CVE-2014-3215 [1], which is a local privilege
escalation made possible a because setuid binary turned security knobs
for the warm fuzzy feelings.
So, no, barring a really good reason and a very convincing argument
about why it would be safe, I won't ack any attempt to add xattr knobs
to change privilege evolution rules like that. If you really want to
turn knobs to make your system feel safer and be safe at the same
time, please learn exactly what all the knobs do first and, while
you're at it, please think carefully about how they interact.
--Andy
[1] See http://openwall.com/lists/oss-security/2014/04/29/7 and much
related discussion
On Thu, Nov 05, 2015 at 11:01:07AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <[email protected]> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Am Do den 5. Nov 2015 um 18:34 schrieb Serge E. Hallyn:
> >> > Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> >> > > I think if you follow your idea to its logical conclusions, you end
> >> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> >> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
> >> >
> >> > That I did miss out and seems to be the solution for the problem. So
> >> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
> >> > gets other caps should solve it?
> >>
> >> No that doesn't work, you have to use prctl to set those bits. If you
> >> can get your system to be fully rootless, you can have init or initramfs
> >> do this for you. It'll mean that root and setuid-root binaries have no
> >> automatic privileges beside owning host (proc/sys) files.
> >
> > So this is not helping much. But for me it is at least an idea to how to
> > have abient capabilities _and_ full control for admin. It would be an
> > un-capability but at least would allow the admin to change the
> > behaviour.
> >
> > Another one, that would be much better would be something like
> > cap_ambient_cap capability to explicitly allow the use of ambient
> > capabilities.
> >
> > I have to say that I do not know much about prctl. Just reading the man
> > page currently. But this seems to be about the second way of taking away
> > rights from UID 0 instead of explicitly giving rights to selective
> > binaries.
Not exactly. It's restoring the full unadulterated use of posix
capabilities.
> OK, everyone, take a deep breath please.
>
> Somewhere very high up on my personal list of generally applicable
> security advice: do not turn security knobs for the warm fully
> feelings. Let me repeat that in all caps: DO NOT TURN SECURITY KNOBS
> FOR THE WARM FUZZY FEELINGS.
>
> When a whole bunch of us designed and iterated on how ambient caps
> would work, we were very careful that they would *not* break
> pre-existing assumptions that SUID programs could make. Securebits
> are very different: they very much do break pre-existing assumptions.
... thought i was clear about that.
> See, for example, CVE-2014-3215 [1], which is a local privilege
> escalation made possible a because setuid binary turned security knobs
> for the warm fuzzy feelings.
Which is why I wonder whether a mailing list - a very slow one - where
projects wanting to discuss how to best integrate with capabilities and
nnp could go for discussion, would be useful. Very slow because for
each project 1+ people on the list would need to put in some time to
figure out what the project really needs.
> So, no, barring a really good reason and a very convincing argument
> about why it would be safe, I won't ack any attempt to add xattr knobs
> to change privilege evolution rules like that. If you really want to
> turn knobs to make your system feel safer and be safe at the same
> time, please learn exactly what all the knobs do first and, while
> you're at it, please think carefully about how they interact.
>
> --Andy
>
> [1] See http://openwall.com/lists/oss-security/2014/04/29/7 and much
> related discussion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
Am Do den 5. Nov 2015 um 23:08 schrieb Serge E. Hallyn:
> On Thu, Nov 05, 2015 at 11:01:07AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <[email protected]> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA512
> > >
> > > Am Do den 5. Nov 2015 um 18:34 schrieb Serge E. Hallyn:
> > >> > Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> > >> > > I think if you follow your idea to its logical conclusions, you end
> > >> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> > >> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
> > >> >
> > >> > That I did miss out and seems to be the solution for the problem. So
> > >> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
> > >> > gets other caps should solve it?
> > >>
> > >> No that doesn't work, you have to use prctl to set those bits. If you
> > >> can get your system to be fully rootless, you can have init or initramfs
> > >> do this for you. It'll mean that root and setuid-root binaries have no
> > >> automatic privileges beside owning host (proc/sys) files.
> > >
> > > So this is not helping much. But for me it is at least an idea to how to
> > > have abient capabilities _and_ full control for admin. It would be an
> > > un-capability but at least would allow the admin to change the
> > > behaviour.
> > >
> > > Another one, that would be much better would be something like
> > > cap_ambient_cap capability to explicitly allow the use of ambient
> > > capabilities.
> > >
> > > I have to say that I do not know much about prctl. Just reading the man
> > > page currently. But this seems to be about the second way of taking away
> > > rights from UID 0 instead of explicitly giving rights to selective
> > > binaries.
>
> Not exactly. It's restoring the full unadulterated use of posix
> capabilities.
- -v
> > OK, everyone, take a deep breath please.
> >
> > Somewhere very high up on my personal list of generally applicable
> > security advice: do not turn security knobs for the warm fully
> > feelings. Let me repeat that in all caps: DO NOT TURN SECURITY KNOBS
> > FOR THE WARM FUZZY FEELINGS.
> >
> > When a whole bunch of us designed and iterated on how ambient caps
> > would work, we were very careful that they would *not* break
> > pre-existing assumptions that SUID programs could make.
I never talked about capabilities _and_ SUID, I always talked about
capabilities _instead_ of SUID. I want to get rid of the SUIDs.
> > Securebits
> > are very different: they very much do break pre-existing assumptions.
>
> ... thought i was clear about that.
What I read about, that ist clear for me too.
> > See, for example, CVE-2014-3215 [1], which is a local privilege
> > escalation made possible a because setuid binary turned security knobs
> > for the warm fuzzy feelings.
Hmm.. That is exactly what I fear about ambient capabilities too. Maybe
I am a bit more paranoid than the author of ambient capabilities but I
droved good with that paranoia level in the past.
> > So, no, barring a really good reason and a very convincing argument
> > about why it would be safe, I won't ack any attempt to add xattr knobs
> > to change privilege evolution rules like that. If you really want to
> > turn knobs to make your system feel safer and be safe at the same
> > time, please learn exactly what all the knobs do first and, while
> > you're at it, please think carefully about how they interact.
Well, I think I have a good understanding about capabilities. I just
think that we talk at cross purposes.
I never ever talked about using capabilities in _combination_ with SUID.
That was brought to the line by others and, how I read the patch that
brought ambient capabilities in, the main reason for it.
But that left out completely the, I think more important, usecase of
_removing_ SUID completely and _replacing_ it with very tight capability
setting. And that is what I always talked about.
I did not know about that "security bits", shame on me. But I do not
think that they are any kind of solution for the problem that ambient
capabilities brought into the kernel. Nor do I think that they change
any about the second usecase I always talked about.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWPLIGAAoJEKZ8CrGAGfaspF8MAKst2DUJ6id4VcPFZGbC6Koe
DROSPWJpZ2+5kW5q4hHX5+E+pQls3ipDwi0K+HyhqjTOXZbRC4Irv8RynbZBgvmN
C7wL2H9o+zjnK29XTlZf7Gr2nCYw/ct10CMtXm56OhIaZcEhb9yNDXa5X+wiPy+B
qVP8xGdFVORa7ziQnyv7j8TRMGejT3qkX+vxLB9bfX5KvuuBgg0X7JIVMqFET6By
HaKWAoVEWoRNbifbOiG0FRq7z8usXB0/5Yhz9u89n4MiGf14bQb4ivrJStIyMb4q
BxHZxQsEtf+wSpd4itoICdKl2vUO5J46mNc3vNvi0tCv1EKIff8HvQRjAYQYpYB9
Vn862aXUQlFrM5z7QjywhYH4que5Xs8PRP+zBsh2eVCZgecwkt7aUh+zK1FzBaWG
Rr+vYwZdObMYQjA3/1v4sQhJmINO0A5yGgLjRCSO1uirU+gjNScXRmGCyvidzaSR
eOlfcv34EfAxzDUrT/X7TSTph308W8s6y3Em9prbKA==
=8opp
-----END PGP SIGNATURE-----
On Fri, Nov 06, 2015 at 02:58:36PM +0100, Klaus Ethgen wrote:
> But that left out completely the, I think more important, usecase of
> _removing_ SUID completely and _replacing_ it with very tight capability
> setting. And that is what I always talked about.
I don't believe this is ever going to be possible. And I'm not
talking about it from a technical perspective, but from a practical
and cultural perspective.
The problem with removing SUID and inheritance completely is that you
have to anticipate all possible use cases where a system administrator
might want to use a root shell. This means analyzing all possible use
cases for all possible system administrators how they might need to
use a root shell to fix or management a system, and then either (a)
provide a new, specialized tool that solves that particular use case,
while respecting the rules of least privilege, or (b) figure out how
to expand that executable's fI mask, and worse, if that executable
fork and exec's helper programs, those helper programs will need to
have expanded fI masks. And that's if all of the commands that a
system administrator needs to run are compiled executables. Now
consider what happens when a system administrator needs to run python,
perl, or shell scripts with elevated privileges.
You maybe can solve this in a very restricted environment; say, one
really dedicated user who can tweak his or her own's fI masks because
hopefully he or she can anticipate all possible use cases. But in the
general case? For a general purpose distribution? Good luck with that.
Schemes like this could work if you are willing to essentially outlaw
all administrative shell/perl/python scripts. Otherwise, the fact
that /bin/sh, /bin/perl, and /bin/python essentially have an unlimited
fI mask means the whole system has a hole you can drive a truck hole,
in which case, what's the point of going through the whole effort?
In the light of that, using things like ambient capabilities, or using
setuid binary that immediately drops all caps that it needs, is
probably the best we're going to get.
Regards,
- Ted
On Fri, Nov 6, 2015 at 7:53 AM, Theodore Ts'o <[email protected]> wrote:
> On Fri, Nov 06, 2015 at 02:58:36PM +0100, Klaus Ethgen wrote:
>> But that left out completely the, I think more important, usecase of
>> _removing_ SUID completely and _replacing_ it with very tight capability
>> setting. And that is what I always talked about.
>
> I don't believe this is ever going to be possible. And I'm not
> talking about it from a technical perspective, but from a practical
> and cultural perspective.
>
> The problem with removing SUID and inheritance completely is that you
> have to anticipate all possible use cases where a system administrator
> might want to use a root shell. This means analyzing all possible use
> cases for all possible system administrators how they might need to
> use a root shell to fix or management a system, and then either (a)
> provide a new, specialized tool that solves that particular use case,
> while respecting the rules of least privilege, or (b) figure out how
> to expand that executable's fI mask, and worse, if that executable
> fork and exec's helper programs, those helper programs will need to
> have expanded fI masks. And that's if all of the commands that a
> system administrator needs to run are compiled executables. Now
> consider what happens when a system administrator needs to run python,
> perl, or shell scripts with elevated privileges.
>
> You maybe can solve this in a very restricted environment; say, one
> really dedicated user who can tweak his or her own's fI masks because
> hopefully he or she can anticipate all possible use cases. But in the
> general case? For a general purpose distribution? Good luck with that.
>
> Schemes like this could work if you are willing to essentially outlaw
> all administrative shell/perl/python scripts. Otherwise, the fact
> that /bin/sh, /bin/perl, and /bin/python essentially have an unlimited
> fI mask means the whole system has a hole you can drive a truck hole,
> in which case, what's the point of going through the whole effort?
>
> In the light of that, using things like ambient capabilities, or using
> setuid binary that immediately drops all caps that it needs, is
> probably the best we're going to get.
What could be achievable, at least on some distros and with some
userspace changes, is to get rid of all privilege elevation on exec.
That is, turn off SUID, use ambient capabilities instead of file
capability masks, and use a systemwide privilege broker.
Of course, in this setting, the current sudo tool wouldn't work. But
there's nothing fundamental stopping someone from writing a mostly
drop-in sudo replacement that authenticates itself to a daemon and
asks the daemon to fork a privileged child on the sudo-replacement's
behalf.
It would probably be a lot safer in the long run, because all of the
environment (env vars and everything else about execution state)
sanitation issues that plague setuid programs become non-issues.
--Andy
On 11/6/2015 7:53 AM, Theodore Ts'o wrote:
> On Fri, Nov 06, 2015 at 02:58:36PM +0100, Klaus Ethgen wrote:
>> But that left out completely the, I think more important, usecase of
>> _removing_ SUID completely and _replacing_ it with very tight capability
>> setting. And that is what I always talked about.
> I don't believe this is ever going to be possible. And I'm not
> talking about it from a technical perspective, but from a practical
> and cultural perspective.
There have been rootless systems (e.g. Trusted Irix) in the past.
They sold to a very restricted market and were never widely adopted.
The inevitable first question from the admins was
"How do I get *real* root?"
I agree that culturally it's a hard sell. Once someone gets a taste
for privilege it's tough to get them to give it up. It's a major
problem even in embedded systems, where people are still doing development
in a root shell.
I was on the POSIX group that defined capabilities. I hate to
say it, but the evidence is that we failed. We've had capabilities
in the kernel for how long? If we haven't been able to make the
transition away from root by now, maybe it's time to reexamine the
way we planned to do it. As I said, we know it's possible. There
are existence proofs. If the product isn't moving, maybe it is time
to put something else on the shelf.
>
> The problem with removing SUID and inheritance completely is that you
> have to anticipate all possible use cases where a system administrator
> might want to use a root shell. This means analyzing all possible use
> cases for all possible system administrators how they might need to
> use a root shell to fix or management a system, and then either (a)
> provide a new, specialized tool that solves that particular use case,
> while respecting the rules of least privilege, or (b) figure out how
> to expand that executable's fI mask, and worse, if that executable
> fork and exec's helper programs, those helper programs will need to
> have expanded fI masks. And that's if all of the commands that a
> system administrator needs to run are compiled executables. Now
> consider what happens when a system administrator needs to run python,
> perl, or shell scripts with elevated privileges.
>
> You maybe can solve this in a very restricted environment; say, one
> really dedicated user who can tweak his or her own's fI masks because
> hopefully he or she can anticipate all possible use cases. But in the
> general case? For a general purpose distribution? Good luck with that.
>
> Schemes like this could work if you are willing to essentially outlaw
> all administrative shell/perl/python scripts. Otherwise, the fact
> that /bin/sh, /bin/perl, and /bin/python essentially have an unlimited
> fI mask means the whole system has a hole you can drive a truck hole,
> in which case, what's the point of going through the whole effort?
>
> In the light of that, using things like ambient capabilities, or using
> setuid binary that immediately drops all caps that it needs, is
> probably the best we're going to get.
>
> Regards,
>
> - Ted
> --
> 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/
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Fr den 6. Nov 2015 um 16:53 schrieb Theodore Ts'o:
> On Fri, Nov 06, 2015 at 02:58:36PM +0100, Klaus Ethgen wrote:
> > But that left out completely the, I think more important, usecase of
> > _removing_ SUID completely and _replacing_ it with very tight capability
> > setting. And that is what I always talked about.
>
> I don't believe this is ever going to be possible. And I'm not
> talking about it from a technical perspective, but from a practical
> and cultural perspective.
>
> The problem with removing SUID and inheritance completely is that you
> have to anticipate all possible use cases where a system administrator
> might want to use a root shell. This means analyzing all possible use
> cases for all possible system administrators how they might need to
> use a root shell to fix or management a system,
That is not my interest at all. I wan't to get rid of all the SUID
_binaries_ that are used by _normal_ users. (And me counting as normal
user in the most time too.)
I do not want to remove root or something like that. For that task,
capabilities is definitively the wrong tool.
> and then either (a)
> provide a new, specialized tool that solves that particular use case,
> while respecting the rules of least privilege, or (b) figure out how
> to expand that executable's fI mask, and worse, if that executable
> fork and exec's helper programs, those helper programs will need to
> have expanded fI masks. And that's if all of the commands that a
> system administrator needs to run are compiled executables. Now
> consider what happens when a system administrator needs to run python,
> perl, or shell scripts with elevated privileges.
Independent of, that I do not want to address this, I never want to have
a shell (sh, perl, python, ruby, ...) in such a construct.
> In the light of that, using things like ambient capabilities, or using
> setuid binary that immediately drops all caps that it needs, is
> probably the best we're going to get.
I do never want that! Even to think about such a way to give any shell
raised rights is horrible! And that horrible idea is it that makes all
the ambient capabilities that bad.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWPOm+AAoJEKZ8CrGAGfaseE0L+gKhc7DLjkcfVMtYQHFpxTTt
C/12GrwxUl+rumO+FPlFhuRBFwFFpLk4BNul6M7MeIJcV8DjDGDTWeRV30/0+gpA
qzxpC5lHeNxdgpvom9/wcHEDHXSmZ134zDRcbHVvfn9VGOSi/aZcBvK3Cl5UJPsI
vOXbiVeFFRYISEWyoAt9FV/w8z4xFdd6yFZHlZ33mX/FaUNk2Rtdlpwe+lPq6CgO
f1mrC4AANY2Hl0sAtoeBhHcscE6lUIujs1katxCwdG5BHSVjaWbvbnLtyKgC6XoN
ttoq+jTCsUVo0k3Aae4s6zgfPt3LfrT8ymwlNRNgimD1jq10yM8hsPPXTr9yqvhj
VNp+OqozuGvqLoMQApvR3mV0AujBruLmC8g7xMrpmubrQzp+96rUXj82YYtCC9/l
++zTsz5Ik8G/rW/AevDWow0HilaNnqMZeNXevjKNiUK/jGhL1S+4I0bh+PbKrjqc
bqC/WDhcimkle5sGH9q6NeQBAsC7mRTsgKOULCVnEw==
=9dzb
-----END PGP SIGNATURE-----
On Fri, Nov 06, 2015 at 09:51:15AM -0800, Casey Schaufler wrote:
> On 11/6/2015 7:53 AM, Theodore Ts'o wrote:
> > On Fri, Nov 06, 2015 at 02:58:36PM +0100, Klaus Ethgen wrote:
> >> But that left out completely the, I think more important, usecase of
> >> _removing_ SUID completely and _replacing_ it with very tight capability
> >> setting. And that is what I always talked about.
> > I don't believe this is ever going to be possible. And I'm not
> > talking about it from a technical perspective, but from a practical
> > and cultural perspective.
>
> There have been rootless systems (e.g. Trusted Irix) in the past.
> They sold to a very restricted market and were never widely adopted.
> The inevitable first question from the admins was
>
> "How do I get *real* root?"
Ok, but there's a difference between not supporting a real root login
at all, and having most or all regular system services working without
it.
ffs, ping is still often setuid-root.
> I agree that culturally it's a hard sell. Once someone gets a taste
> for privilege it's tough to get them to give it up. It's a major
> problem even in embedded systems, where people are still doing development
> in a root shell.
>
> I was on the POSIX group that defined capabilities. I hate to
> say it, but the evidence is that we failed. We've had capabilities
> in the kernel for how long? If we haven't been able to make the
> transition away from root by now, maybe it's time to reexamine the
Several times we've discussed why - for instance after Ted's indicting
LSS keynote. There have been some very pedestrian reasons why. The two
sadest but also hardest to overcome ones were lack of xattr support in
some filesystems, and in some packaging systems. The fact that, as a
distro, you have to support use of packages without support for xattrs
means you always have to still add the setuid bit, and if you have to do
that, it's really better to *only* but cleanly support setuid.
And so ping is setuid-root.
And we've actually made things worse for now, because you cannot write
xattrs froma user namespace. So many default containers, again, cannot
use file capabilities unless the host admin installs the packages. (I
do plan to write patch to fix that, but hasn't been done that)
The other problem is imo there needs to be a better support system for
projects which want to switch. That's why I'm really thinking we
should have a mailing list dedicated to helping projects properly
design their use of capabilities (or nnp or setresuid, probably)
Another possible reason would be that it is not portable. If that's
holding people back, then that feels like a reason to just replace the
whole shebang with something like capsicum.
On Fri, Nov 06, 2015 at 06:56:20PM +0100, Klaus Ethgen wrote:
> Am Fr den 6. Nov 2015 um 16:53 schrieb Theodore Ts'o:
> > In the light of that, using things like ambient capabilities, or using
> > setuid binary that immediately drops all caps that it needs, is
> > probably the best we're going to get.
>
> I do never want that! Even to think about such a way to give any shell
> raised rights is horrible! And that horrible idea is it that makes all
> the ambient capabilities that bad.
I sympathize with your point of view, but Christoph's use case really was
a good one. A piece of system configuration software needs to do some
networking setup with some privilege, including calling scripts. It can
either do so as root or not at all - polluting every program that will end
up getting called with fI is not only ugly but simply doesn't work (because
scripts). Saying that the whole thing must be written as self-contained
executable that never needs to be re-execed is frequently unrealistic.
So this allows a piece of software to run with reduce privilege, and it
is an improvement over the previous state of affairs.
It is not intended for login shells.
I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
the current set of rules which removes bits from pA whenever doing an
action which capability-aware software does something which it would have
reasonably expected to drop privilege is a nice safeguard.
-serge
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Guys,
Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:
> On Fri, Nov 06, 2015 at 06:56:20PM +0100, Klaus Ethgen wrote:
> > Am Fr den 6. Nov 2015 um 16:53 schrieb Theodore Ts'o:
> > > In the light of that, using things like ambient capabilities, or using
> > > setuid binary that immediately drops all caps that it needs, is
> > > probably the best we're going to get.
> >
> > I do never want that! Even to think about such a way to give any shell
> > raised rights is horrible! And that horrible idea is it that makes all
> > the ambient capabilities that bad.
>
> I sympathize with your point of view, but Christoph's use case really was
> a good one.
I don't think so. Read on...
> A piece of system configuration software needs to do some
> networking setup with some privilege, including calling scripts. It can
> either do so as root or not at all - polluting every program that will end
> up getting called with fI is not only ugly but simply doesn't work (because
> scripts). Saying that the whole thing must be written as self-contained
> executable that never needs to be re-execed is frequently unrealistic.
> So this allows a piece of software to run with reduce privilege, and it
> is an improvement over the previous state of affairs.
Having some scripts in the process is definitively a nightmare to
control. That should be prevented wherever possible. And usually it is
as the scripts might be used for computing some values that are used
later in privileged stuff.
However, that usecase has one more flaw I think. It is the human nature.
Someone that create a tool made for running as root or especially SUID
is usually careful to do so. If they know right now that the tool is
never run as root, then they don't care about many thinks that needs to
get addressed for root stuff.
Good example are all that userspace python tools that throw all that
stack traces around the users ears (I don't know if that saying exists
in English...) instead of giving proper error messages.
> I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
> prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
> the current set of rules which removes bits from pA whenever doing an
> action which capability-aware software does something which it would have
> reasonably expected to drop privilege is a nice safeguard.
Well, not really. You can only prevent ambient capabilities to be given
to tools you don't want to have any capabilities by setting that tool
SUID or setting just one random capability for it.
By the way, guys, can we start to _not_ add every one in this discussion
to the Cc? Currently I get every mail twice. One from the list and one
from Cc. I still leave all Ccs intact with this mail but I would prefer
to just reply to the list. If anybody is not reading the list and would
like to get the mail, please insist.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWPdpRAAoJEKZ8CrGAGfasAaUL/jLZg82kUfL5ByyZ5bUINxvY
kTRIaUTkgSRwkMQF5p+ILkVajE/YVAfD4MZFdZrB62PNbhvvCdy4R9jefVPcBlae
CTJuaDguWr2UZvPX6C25l2Q/ix2v9K2zOlgbhf23piXisfdLD3b1i6YlpYAJ4MRU
gakxTWylYCUhIt2j6dzlxPGN691o3q59kLa+1wCBXcMXr4gB8i93NjAloS6/ud+/
tC+6Ld+tbJFjoG/3HJ6qBCabaz41HVFnSPPQBohv19lSM1oDjUvH6wO9QGHBxYNN
S8IrBPrsINjm2l4kbNqUexIA+GGn7uPYO1SLjWl/VxfiegT5DfwArYakzsSnpQS/
Y30RlKJHSwl+nP/dxxN2kaqmrrmppcvh0HemKvnJX75UwZ/ROw7ACVCcGZQIqlUs
FssHB/lw48fhMQ5/WYjVRXBIQdbN1tmj9s6r22Vwez4sNst2ak4F+zO7NLwuYwmY
AstL8IyovKSHT52jsASydFBZ4PpG2PsPkZIRIUTLDQ==
=5Iab
-----END PGP SIGNATURE-----
On Sat, Nov 07, 2015 at 12:02:47PM +0100, Klaus Ethgen wrote:
> Hi Guys,
>
> Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:
> > I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
> > prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
> > the current set of rules which removes bits from pA whenever doing an
> > action which capability-aware software does something which it would have
> > reasonably expected to drop privilege is a nice safeguard.
>
> Well, not really. You can only prevent ambient capabilities to be given
> to tools you don't want to have any capabilities by setting that tool
> SUID or setting just one random capability for it.
Right, I didn't say you could say "/bin/foo is never run with capabilities."
Rather, if a piece of software specifically tries to drop all privilege
before running a piece of software, then ambient capabilities is designed
to honor that.
> By the way, guys, can we start to _not_ add every one in this discussion
> to the Cc? Currently I get every mail twice. One from the list and one
> from Cc. I still leave all Ccs intact with this mail but I would prefer
> to just reply to the list. If anybody is not reading the list and would
> like to get the mail, please insist.
That is (a) hard to do becase we don't know who is on the list, and (2)
not useful with lkml in particular because many people read only email
directly To them, not lkml email. (My procmail filters my name to my
inbox, so I typically get 3-4 copies; easily handled)
On 2015-11-07 06:02, Klaus Ethgen wrote:
> Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:
>> A piece of system configuration software needs to do some
>> networking setup with some privilege, including calling scripts. It can
>> either do so as root or not at all - polluting every program that will end
>> up getting called with fI is not only ugly but simply doesn't work (because
>> scripts). Saying that the whole thing must be written as self-contained
>> executable that never needs to be re-execed is frequently unrealistic.
>> So this allows a piece of software to run with reduce privilege, and it
>> is an improvement over the previous state of affairs.
>
> Having some scripts in the process is definitively a nightmare to
> control. That should be prevented wherever possible. And usually it is
> as the scripts might be used for computing some values that are used
> later in privileged stuff.
It's still unavoidable in a number of cases. It's easy to re-write
scripts to fit any local configuration. It's not anywhere near as easy
to re-write a compiled program to account for any local configuration.
>
> However, that usecase has one more flaw I think. It is the human nature.
>
> Someone that create a tool made for running as root or especially SUID
> is usually careful to do so. If they know right now that the tool is
> never run as root, then they don't care about many thinks that needs to
> get addressed for root stuff.
>
> Good example are all that userspace python tools that throw all that
> stack traces around the users ears (I don't know if that saying exists
> in English...) instead of giving proper error messages.
This is debatable. While the app should be giving a user friendly error
message, getting a stack-trace and the exception name (and the
exceptions are usually sanely named) is still far better than just
getting something like 'Segmentation Fault', or just returning the error
in the return code. There is no added security from not providing the
stack-trace because there is no data leaked by it (it contains no
information about the contents of variables, and function names and
included libraries can easily be seen by just looking at the python
program itself).
>
>> I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
>> prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
>> the current set of rules which removes bits from pA whenever doing an
>> action which capability-aware software does something which it would have
>> reasonably expected to drop privilege is a nice safeguard.
>
> Well, not really. You can only prevent ambient capabilities to be given
> to tools you don't want to have any capabilities by setting that tool
> SUID or setting just one random capability for it.
>
> By the way, guys, can we start to _not_ add every one in this discussion
> to the Cc? Currently I get every mail twice. One from the list and one
> from Cc. I still leave all Ccs intact with this mail but I would prefer
> to just reply to the list. If anybody is not reading the list and would
> like to get the mail, please insist.
If you're getting duplicates with the same Message-ID header, then your
mail-server is (arguably) broken. It should be delivering exactly one
copy of a message with a given Message-ID: header (this is really a
de-facto standard, GMail, Yahoo, and most other mail-providers do this,
as does Exchange. Postfix does not, but it's pretty easy to work around
with some filtering and procmail).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Mo den 9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn:
> >Having some scripts in the process is definitively a nightmare to
> >control. That should be prevented wherever possible. And usually it is
> >as the scripts might be used for computing some values that are used
> >later in privileged stuff.
> It's still unavoidable in a number of cases. It's easy to re-write scripts
> to fit any local configuration. It's not anywhere near as easy to re-write
> a compiled program to account for any local configuration.
I would not only say that it is avoidable, it is the worst that can
happen.
Usually a shell is calling a binary to do the real work. So it should
even never ever needed to have some raised privileges for the shell.
> >Good example are all that userspace python tools that throw all that
> >stack traces around the users ears (I don't know if that saying exists
> >in English...) instead of giving proper error messages.
> This is debatable. While the app should be giving a user friendly error
> message, getting a stack-trace and the exception name (and the exceptions
> are usually sanely named) is still far better than just getting something
> like 'Segmentation Fault', or just returning the error in the return code.
> There is no added security from not providing the stack-trace because there
> is no data leaked by it (it contains no information about the contents of
> variables, and function names and included libraries can easily be seen by
> just looking at the python program itself).
My pointing to that python problem is not about security then about how
lazy some developer are. And lazyness and security is nothing that can
go together.
> >By the way, guys, can we start to _not_ add every one in this discussion
> >to the Cc? Currently I get every mail twice. One from the list and one
> >from Cc. I still leave all Ccs intact with this mail but I would prefer
> >to just reply to the list. If anybody is not reading the list and would
> >like to get the mail, please insist.
> If you're getting duplicates with the same Message-ID header, then your
> mail-server is (arguably) broken.
I do not know any mailserver that cares about message-ids. Even more,
which one is the original one if they differ in body? (as they do for
example in this list.)
It it even more broken as some (surely broken) MUAs reuse message ids.
> It should be delivering exactly one copy of a message with a given
> Message-ID: header (this is really a de-facto standard,
I wouldn't say so.
> GMail, Yahoo, and most other mail-providers do this, as does
> Exchange.
I would say, they are broken as they suppress users data.
> Postfix does not, but it's pretty easy to work around with some
> filtering and procmail).
Well, pestfix dos it right here. A MTA has to transport the mails and
never ever suppress some.
But lets keep that stuff offlist, it is OT. I will go ahead with group
reply.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWQNaJAAoJEKZ8CrGAGfasC9UL/3ipt684NO2m5P6YLjrLGqPY
9TnEJz4ks0uKJsOPMXX7v54eUG6Jv0o1uj28aI/pcFxszBRALLpar2TAuAz6dWID
0hhB2kt/3TaEV00aOP5fzl/BzjwozxYiavYri10B4xqbLOtJEpKgCWNhLpMdEqGO
ksgSx/Qqo+lB49uTjueC63Z3dU4T1CL6+iUbPx6MeLURGI1rYn4yye6n33AlceEL
/y5jEfscxl9htAtC6O9DJHGp6EgN1Yc7rXdSIYVNqXt3GKTAnfmeVlnt8EO+kOmg
zA2fzIXMvt2ZIOWF6TCCSE9tghuFY6S2gnVpmwR0m02JqD+vTarlbzldeDbsI+bg
avcEAdmGBfMf1WibAHAazt/GUVMKaMw5rPhj7nXrv5rx+x6NvjNoY1aBb8yEbGjR
nvNOcHp6tbMJuBHBWBwtcV1HJafvNm8GzhAVYwQf0efJY4x46E2xDfgaS4hgXvEN
yhtGkX5OEVaEvixB2Lkt37UUF8Ix3kqMweW7+sp5vw==
=nlsD
-----END PGP SIGNATURE-----
On 2015-11-09 12:23, Klaus Ethgen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Mo den 9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn:
>>> Having some scripts in the process is definitively a nightmare to
>>> control. That should be prevented wherever possible. And usually it is
>>> as the scripts might be used for computing some values that are used
>>> later in privileged stuff.
>> It's still unavoidable in a number of cases. It's easy to re-write scripts
>> to fit any local configuration. It's not anywhere near as easy to re-write
>> a compiled program to account for any local configuration.
>
> I would not only say that it is avoidable, it is the worst that can
> happen.
Scripts will always be necessary unless you have a purpose built system
that never gets updated or relocated, and never has any changes to the
hardware (and guess what, you use scripts constantly if you use the
command-line, option syntax and configuration files are technically
domain-specific scripting languages).
>
> Usually a shell is calling a binary to do the real work. So it should
> even never ever needed to have some raised privileges for the shell.
Unless you need the binary to be run with some privileges and can't
reasonably use capabilities on it (for example, it's a lot of work to
maintain a system with no set{u,g}id binaries on it and keep the
software up-to-date on it as well).
>
>>> Good example are all that userspace python tools that throw all that
>>> stack traces around the users ears (I don't know if that saying exists
>>> in English...) instead of giving proper error messages.
>> This is debatable. While the app should be giving a user friendly error
>> message, getting a stack-trace and the exception name (and the exceptions
>> are usually sanely named) is still far better than just getting something
>> like 'Segmentation Fault', or just returning the error in the return code.
>> There is no added security from not providing the stack-trace because there
>> is no data leaked by it (it contains no information about the contents of
>> variables, and function names and included libraries can easily be seen by
>> just looking at the python program itself).
>
> My pointing to that python problem is not about security then about how
> lazy some developer are. And lazyness and security is nothing that can
> go together.
That depends on what you mean by lazy. Scripts can't do core-dumps
(there is no practical way to do a core-dump from a script and still be
reasonably easy to debug), so they have to do something to provide data
so developers can debug it. By having such things just dump a
stacktrace, the developers are making it easier for stuff like ABRT and
whatever Ubuntu uses for automated bug reporting to actually report
things, which in turn makes handling bug reports more efficient (and a
desire for efficiency is _not_ the same as being lazy).
>>> By the way, guys, can we start to _not_ add every one in this discussion
>>> to the Cc? Currently I get every mail twice. One from the list and one
>> >from Cc. I still leave all Ccs intact with this mail but I would prefer
>>> to just reply to the list. If anybody is not reading the list and would
>>> like to get the mail, please insist.
>> If you're getting duplicates with the same Message-ID header, then your
>> mail-server is (arguably) broken.
>
> I do not know any mailserver that cares about message-ids. Even more,
> which one is the original one if they differ in body? (as they do for
> example in this list.)
>
> It it even more broken as some (surely broken) MUAs reuse message ids.
>
>> It should be delivering exactly one copy of a message with a given
>> Message-ID: header (this is really a de-facto standard,
>
> I wouldn't say so.
The Message-ID header is supposed to be unique for the lifetime of the
message (which effectively means almost forever for stuff on LKML, as
it's archived). If you are getting multiple copies of a message with
the same Message-ID header and different content in the message, then
something is very broken, and if a MUA is reusing Message-ID's, then
someone needs to file a bug against that MUA.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Mo den 9. Nov 2015 um 20:02 schrieb Austin S Hemmelgarn:
> >>>Having some scripts in the process is definitively a nightmare to
> >>>control. That should be prevented wherever possible. And usually it is
> >>>as the scripts might be used for computing some values that are used
> >>>later in privileged stuff.
> >>It's still unavoidable in a number of cases. It's easy to re-write scripts
> >>to fit any local configuration. It's not anywhere near as easy to re-write
> >>a compiled program to account for any local configuration.
> >
> >I would not only say that it is avoidable, it is the worst that can
> >happen.
> Scripts will always be necessary unless you have a purpose built system that
> never gets updated or relocated, and never has any changes to the hardware
> (and guess what, you use scripts constantly if you use the command-line,
> option syntax and configuration files are technically domain-specific
> scripting languages).
Don't be silly! We talk about privileged capabilities for unprivileged
useraccounts.
No shell will ever need such capabilities. It is the tools that are
_called_ by the shell, that needs this capabilities. And there is no
reason why the capabilities should not be explicitly assigned to that
binaries only.
> >Usually a shell is calling a binary to do the real work. So it should
> >even never ever needed to have some raised privileges for the shell.
> Unless you need the binary to be run with some privileges and can't
> reasonably use capabilities on it (for example, it's a lot of work to
> maintain a system with no set{u,g}id binaries on it and keep the software
> up-to-date on it as well).
Then work on a way to be able to do so.
I _am_ able to do so. Currently I use puppet to enforce that. But you
can use every other tool what you like.
> >>>Good example are all that userspace python tools that throw all that
> >>>stack traces around the users ears (I don't know if that saying exists
> >>>in English...) instead of giving proper error messages.
> >>This is debatable. While the app should be giving a user friendly error
> >>message, getting a stack-trace and the exception name (and the exceptions
> >>are usually sanely named) is still far better than just getting something
> >>like 'Segmentation Fault', or just returning the error in the return code.
> >>There is no added security from not providing the stack-trace because there
> >>is no data leaked by it (it contains no information about the contents of
> >>variables, and function names and included libraries can easily be seen by
> >>just looking at the python program itself).
Independent what I already told, I don't find that python stacktraces
that every second python program is puking me in my shell is useful.
Usually the programming fault is somewhere in the middle. So good look
with searching. It is a pain in the ass! Just my 2ct.
> >My pointing to that python problem is not about security then about how
> >lazy some developer are. And lazyness and security is nothing that can
> >go together.
> That depends on what you mean by lazy. Scripts can't do core-dumps (there
> is no practical way to do a core-dump from a script and still be reasonably
> easy to debug), so they have to do something to provide data so developers
> can debug it.
I have no problem when a developer is using that but they are puking
that traces to every user. That is the problem.
> By having such things just dump a stacktrace, the developers
> are making it easier for stuff like ABRT and whatever Ubuntu uses for
> automated bug reporting to actually report things, which in turn makes
> handling bug reports more efficient (and a desire for efficiency is _not_
> the same as being lazy).
Look around, there are other distributions than Ubuntu out there.
And to be honest, Ubuntus bugtracker is a pain. The only bugtracker that
I seen until now that is less pain is the one from Debian. You can use
it from the command line and it has a feature-rich mail API.
> >>>By the way, guys, can we start to _not_ add every one in this discussion
> >>>to the Cc? Currently I get every mail twice. One from the list and one
> >>>from Cc. I still leave all Ccs intact with this mail but I would prefer
> >>>to just reply to the list. If anybody is not reading the list and would
> >>>like to get the mail, please insist.
> >>If you're getting duplicates with the same Message-ID header, then your
> >>mail-server is (arguably) broken.
> >
> >I do not know any mailserver that cares about message-ids. Even more,
> >which one is the original one if they differ in body? (as they do for
> >example in this list.)
> >
> >It it even more broken as some (surely broken) MUAs reuse message ids.
> >
> >>It should be delivering exactly one copy of a message with a given
> >>Message-ID: header (this is really a de-facto standard,
> >
> >I wouldn't say so.
> The Message-ID header is supposed to be unique for the lifetime of the
> message (which effectively means almost forever for stuff on LKML, as it's
> archived). If you are getting multiple copies of a message with the same
> Message-ID header and different content in the message, then something is
> very broken,
Well, did you see that majordomo is adding a footer to every mail? So
you get one mail direct without that footer and one from the list with
that footer. Both mails are different and share the same Message-ID.
> and if a MUA is reusing Message-ID's, then someone needs to
> file a bug against that MUA.
I gave up with that. It is usually some proprietary product and they
don't care.
So, answered that I get very frustrated. We talk about details that have
nothing to do with the main problem. The main problem is that there is
no way to disable ambient capabilities or, even better, to _enable_ them
explicitly if needed. That is a real problem that exists now in the
kernel.
Please focus on that problem!
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWQRA5AAoJEKZ8CrGAGfasuMoMAKzofpijukxtVCdIz6rHcRWC
/5xMMxfZZvCHNN7gCiWNRwg2gBbk2vx2kLYJ5c9Vb6llCsMWmxuMyjjgkK8pHt0D
7hBmiT3jfHqKr/1sRA8AjQ1OK7UWkfrFQYF2JCb/PUgGqpVhXVmDggmu9Dkczyh8
8dFBT94HJ/lVIAJVf+4Y7gXOYnkNupg82pLmIZphAt9yF+lrn6giB6kWWFvtA6iA
GC5R91maK+tUIBu9zVKrGtr07lAcwUX9TB4eiV47ZwWlkzh+ST+uzFjQXXRHtsP4
rXENhKpz8Pzi02GcSt6xdnPv0O8K0rBxUnfCpHuSmVyy/4oNxwEohedsJ9EmUMe6
9V2K+cz/7Z1AZXsfrvyjakOxKnurl/JZgiQH8u+bmduDzZFjCmXOGu85uNZ7bnqv
KQgfZYsuXN59BAwWAiYwzw0UdHNWixyJd1eRGsjsQejF0zJQMO2Zp8kVWE/nj6uc
JIy5UkLrEfsj+QJI8BvCLjQUVfsgMgJKBInGP/NTxQ==
=9BXl
-----END PGP SIGNATURE-----
On Nov 9, 2015 1:29 PM, "Klaus Ethgen" <[email protected]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Mo den 9. Nov 2015 um 20:02 schrieb Austin S Hemmelgarn:
> > >>>Having some scripts in the process is definitively a nightmare to
> > >>>control. That should be prevented wherever possible. And usually it is
> > >>>as the scripts might be used for computing some values that are used
> > >>>later in privileged stuff.
> > >>It's still unavoidable in a number of cases. It's easy to re-write scripts
> > >>to fit any local configuration. It's not anywhere near as easy to re-write
> > >>a compiled program to account for any local configuration.
> > >
> > >I would not only say that it is avoidable, it is the worst that can
> > >happen.
> > Scripts will always be necessary unless you have a purpose built system that
> > never gets updated or relocated, and never has any changes to the hardware
> > (and guess what, you use scripts constantly if you use the command-line,
> > option syntax and configuration files are technically domain-specific
> > scripting languages).
>
> Don't be silly! We talk about privileged capabilities for unprivileged
> useraccounts.
>
> No shell will ever need such capabilities. It is the tools that are
> _called_ by the shell, that needs this capabilities. And there is no
> reason why the capabilities should not be explicitly assigned to that
> binaries only.
>
> > >Usually a shell is calling a binary to do the real work. So it should
> > >even never ever needed to have some raised privileges for the shell.
> > Unless you need the binary to be run with some privileges and can't
> > reasonably use capabilities on it (for example, it's a lot of work to
> > maintain a system with no set{u,g}id binaries on it and keep the software
> > up-to-date on it as well).
>
> Then work on a way to be able to do so.
>
> I _am_ able to do so. Currently I use puppet to enforce that. But you
> can use every other tool what you like.
>
> > >>>Good example are all that userspace python tools that throw all that
> > >>>stack traces around the users ears (I don't know if that saying exists
> > >>>in English...) instead of giving proper error messages.
> > >>This is debatable. While the app should be giving a user friendly error
> > >>message, getting a stack-trace and the exception name (and the exceptions
> > >>are usually sanely named) is still far better than just getting something
> > >>like 'Segmentation Fault', or just returning the error in the return code.
> > >>There is no added security from not providing the stack-trace because there
> > >>is no data leaked by it (it contains no information about the contents of
> > >>variables, and function names and included libraries can easily be seen by
> > >>just looking at the python program itself).
>
> Independent what I already told, I don't find that python stacktraces
> that every second python program is puking me in my shell is useful.
> Usually the programming fault is somewhere in the middle. So good look
> with searching. It is a pain in the ass! Just my 2ct.
>
> > >My pointing to that python problem is not about security then about how
> > >lazy some developer are. And lazyness and security is nothing that can
> > >go together.
> > That depends on what you mean by lazy. Scripts can't do core-dumps (there
> > is no practical way to do a core-dump from a script and still be reasonably
> > easy to debug), so they have to do something to provide data so developers
> > can debug it.
>
> I have no problem when a developer is using that but they are puking
> that traces to every user. That is the problem.
>
> > By having such things just dump a stacktrace, the developers
> > are making it easier for stuff like ABRT and whatever Ubuntu uses for
> > automated bug reporting to actually report things, which in turn makes
> > handling bug reports more efficient (and a desire for efficiency is _not_
> > the same as being lazy).
>
> Look around, there are other distributions than Ubuntu out there.
>
> And to be honest, Ubuntus bugtracker is a pain. The only bugtracker that
> I seen until now that is less pain is the one from Debian. You can use
> it from the command line and it has a feature-rich mail API.
>
> > >>>By the way, guys, can we start to _not_ add every one in this discussion
> > >>>to the Cc? Currently I get every mail twice. One from the list and one
> > >>>from Cc. I still leave all Ccs intact with this mail but I would prefer
> > >>>to just reply to the list. If anybody is not reading the list and would
> > >>>like to get the mail, please insist.
> > >>If you're getting duplicates with the same Message-ID header, then your
> > >>mail-server is (arguably) broken.
> > >
> > >I do not know any mailserver that cares about message-ids. Even more,
> > >which one is the original one if they differ in body? (as they do for
> > >example in this list.)
> > >
> > >It it even more broken as some (surely broken) MUAs reuse message ids.
> > >
> > >>It should be delivering exactly one copy of a message with a given
> > >>Message-ID: header (this is really a de-facto standard,
> > >
> > >I wouldn't say so.
> > The Message-ID header is supposed to be unique for the lifetime of the
> > message (which effectively means almost forever for stuff on LKML, as it's
> > archived). If you are getting multiple copies of a message with the same
> > Message-ID header and different content in the message, then something is
> > very broken,
>
> Well, did you see that majordomo is adding a footer to every mail? So
> you get one mail direct without that footer and one from the list with
> that footer. Both mails are different and share the same Message-ID.
>
> > and if a MUA is reusing Message-ID's, then someone needs to
> > file a bug against that MUA.
>
> I gave up with that. It is usually some proprietary product and they
> don't care.
>
> So, answered that I get very frustrated. We talk about details that have
> nothing to do with the main problem. The main problem is that there is
> no way to disable ambient capabilities or, even better, to _enable_ them
> explicitly if needed. That is a real problem that exists now in the
> kernel.
>
> Please focus on that problem!
No, and I'm now done with this thread. Sorry.
You can use the securebit to turn them off if you care. You can tell
other people that they write privileged programs in the wrong
programming language if you like.
No code change from me appears to be needed or warranted.
--Andy
>
> Regards
> Klaus
> - --
> Klaus Ethgen http://www.ethgen.ch/
> pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJWQRA5AAoJEKZ8CrGAGfasuMoMAKzofpijukxtVCdIz6rHcRWC
> /5xMMxfZZvCHNN7gCiWNRwg2gBbk2vx2kLYJ5c9Vb6llCsMWmxuMyjjgkK8pHt0D
> 7hBmiT3jfHqKr/1sRA8AjQ1OK7UWkfrFQYF2JCb/PUgGqpVhXVmDggmu9Dkczyh8
> 8dFBT94HJ/lVIAJVf+4Y7gXOYnkNupg82pLmIZphAt9yF+lrn6giB6kWWFvtA6iA
> GC5R91maK+tUIBu9zVKrGtr07lAcwUX9TB4eiV47ZwWlkzh+ST+uzFjQXXRHtsP4
> rXENhKpz8Pzi02GcSt6xdnPv0O8K0rBxUnfCpHuSmVyy/4oNxwEohedsJ9EmUMe6
> 9V2K+cz/7Z1AZXsfrvyjakOxKnurl/JZgiQH8u+bmduDzZFjCmXOGu85uNZ7bnqv
> KQgfZYsuXN59BAwWAiYwzw0UdHNWixyJd1eRGsjsQejF0zJQMO2Zp8kVWE/nj6uc
> JIy5UkLrEfsj+QJI8BvCLjQUVfsgMgJKBInGP/NTxQ==
> =9BXl
> -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Andy,
Am Di den 10. Nov 2015 um 1:06 schrieb Andy Lutomirski:
> > So, answered that I get very frustrated. We talk about details that have
> > nothing to do with the main problem. The main problem is that there is
> > no way to disable ambient capabilities or, even better, to _enable_ them
> > explicitly if needed. That is a real problem that exists now in the
> > kernel.
> >
> > Please focus on that problem!
>
> No, and I'm now done with this thread. Sorry.
Sad to hear that.
> You can use the securebit to turn them off if you care.
The problem is that this is not applyable here. Securebits are great for
stuff that is locked in. But here we talk about every process, every
thread in the system. There is simply no way to set securebits with
system start.
> You can tell other people that they write privileged programs in the
> wrong programming language if you like.
Hey, it is not about programming languages. I never said something in
that direction!
I brought python programs for a bad example in programming and how
developers work. But that example can be made in any language. Moreover,
as python is a script language, I would not like it at all, having any
raised capabilities. And that is also valid for perl that I like much
more.
> No code change from me appears to be needed or warranted.
I could come up with a patch, adding a new capability for enabling
ambient capabilities. But as I do not have the full great kernel code
overview, I might miss some security relevant stuff here. Thats why I do
not came up with a patch.
However, when such a patch could have a change to get reviewed my some
more experienced kernel hacker than I am and if there would be a change
to get it into the kernel, I will come up with such a patch.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGbBAEBCgAGBQJWQdspAAoJEKZ8CrGAGfas8B8L+J66vXjZFyxnSjW5iE0mLSS/
CB0kQ9Capyb5eLsDWcjTi+DmO1xTQS+LRJ77HClX6yQUUNTjn4d/kkDtNhm64sER
d0KRvn/B2kOBNhDU1WZ4CELzazaRFMhDEYxNIy4JXuJawB1CDv5O92gjFZ2NjNSp
KN8fP3CaecNJ4d/dBMCPwCPyAKIfm8fwSvHQaI1yguP2MMe2gMtken59+PEbKoqr
m0Y5nJFuZ+LfSedTJdzbINQtmh0iFXEL4hNYaJnz7QyK4wsqwcBET9CZSK2twtsZ
EyxtFizL363ubFdrmdzBZjziC48+U00KEh1Zgrf6xgqvkWcp0KL1v9Fg0kgA5pUa
SNIei5oVDce8sAWerkpqRO+gvvw9mSzGusv7YkDuoRiw8Q1Z42X0Ro5Lyedff2X4
0nRMMH1lU20oJhemUk4X3E9SN2ZxZ4Xwa4OjhWuSUMeLOIEo+ssflFVhFPv45qpr
CHjBZAvfBuiZfkobm6duXrvSX5rtqbf2fGb4fBV0
=518a
-----END PGP SIGNATURE-----
On Tue, Nov 10, 2015 at 12:55:27PM +0100, Klaus Ethgen wrote:
> > You can tell other people that they write privileged programs in the
> > wrong programming language if you like.
>
> Hey, it is not about programming languages. I never said something in
> that direction!
>
> I brought python programs for a bad example in programming and how
> developers work. But that example can be made in any language. Moreover,
> as python is a script language, I would not like it at all, having any
> raised capabilities. And that is also valid for perl that I like much
> more.
And that's the fundamenal problem. Saying that you can only be secure
if **no** scripting languages can be used for **any** privileged
operations is something that _might_ work for you, but it doesn't work
for the 99.99999999999% of the Linux systems out there, many of which
have shell scripts to configure networking, or any host of other
things. Arguably, it's why Posix capalities have utterly failed as
far as usage except for a very, very, very, tiny, limited market.
Scripting languages are just too fundamental to Unix and Linux
systems. And I while I won't speak for Linus here, I suspect this is
one of the places where he'll tell you that this is a prime example of
why many security people are crazy (or in his colorful language,
M***** Monkeys).
You can, after all, simply make any computer 100% secure by the
applied use of thermite --- but the computer won't be very useful
afterwards.
If you want to create a patch, my recommendation would be to do one
that turns off ambient capabilities as a CONFIG option, and hide it
under CONFIG_EXPERT. Or maybe adding a new securebit which disables
ambient capabilities. Whether or not that will be acceptable
upstream, I don't know, mainly because I think a strong case can be
made that such a patch has an audience of one, and adding more
complexity here for an idea which has been time-tested over decades to
be a failure is just not a good idea.
C2 by 92!
- Ted
P.S. What's C2 by 92? The only government mandate that was less
successful than GOSIP. :-) See
https://freedom-to-tinker.com/blog/felten/stupidest-infotech-policy-contest/#comment-15049
for more details.
Hi Ted, hy others in this discussion,
Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o:
> On Tue, Nov 10, 2015 at 12:55:27PM +0100, Klaus Ethgen wrote:
> > > You can tell other people that they write privileged programs in the
> > > wrong programming language if you like.
> >
> > Hey, it is not about programming languages. I never said something in
> > that direction!
> >
> > I brought python programs for a bad example in programming and how
> > developers work. But that example can be made in any language. Moreover,
> > as python is a script language, I would not like it at all, having any
> > raised capabilities. And that is also valid for perl that I like much
> > more.
>
> And that's the fundamenal problem. Saying that you can only be secure
> if **no** scripting languages can be used for **any** privileged
> operations is something that _might_ work for you, but it doesn't work
> for the 99.99999999999% of the Linux systems out there, many of which
> have shell scripts to configure networking, or any host of other
> things. Arguably, it's why Posix capalities have utterly failed as
> far as usage except for a very, very, very, tiny, limited market.
But this is use case 1 of two that I described earlier. And this is the
main use case that is addressed by the ambient capabilities. I'm fine
with that. That is nothing that I would object.
What I want to get fixed is the second use case of capabilities that was
completely ignored by the design of ambient capabilities. It is about
_raising_ explicitly single capabilities for _unprivileged_
binaries/users.
> Scripting languages are just too fundamental to Unix and Linux
> systems. And I while I won't speak for Linus here, I suspect this is
> one of the places where he'll tell you that this is a prime example of
> why many security people are crazy (or in his colorful language,
> M***** Monkeys).
Might be. I like his colorful language. ;-)
> You can, after all, simply make any computer 100% secure by the
> applied use of thermite --- but the computer won't be very useful
> afterwards.
That is true too. But I can try to make it as secure as possible.
> If you want to create a patch, my recommendation would be to do one
> that turns off ambient capabilities as a CONFIG option, and hide it
> under CONFIG_EXPERT.
Would be an approach. Another is to have a kernel command line switch.
> Or maybe adding a new securebit which disables ambient capabilities.
That already exists. But it is not workable for overall system than only
for user namespaces.
However, that two approaches have a big disadvantage that they also
disallow the first use case.
I attached a very simple patch to this mail that introduces a new
capability to enable ambient capabilities. It will not break use case
one but it will give the control back to the admin to control the raised
capabilities for unprivileged binaries and/or users.
However, it is a fast and minimal hack that I want to test before it
gets into any accepted kernel. Please see it as an request for approval.
I was surprised how easily capabilities can be implemented in a secure
way. So I do not expect any security problem from the patch. In fact, it
uses the same way as the securebit stuff to disable them.
> Whether or not that will be acceptable upstream, I don't know, mainly
> because I think a strong case can be made that such a patch has an
> audience of one, and adding more complexity here for an idea which has
> been time-tested over decades to be a failure is just not a good idea.
I wouldn't tell the implementation until now to be a failure. It helped
a lot to keep a system sane. It is true that all distributions ignored
capabilities completely but I don't think that is due the design.
Regards
Klaus
--
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
On 2015-11-10 08:19, Klaus Ethgen wrote:
> Hi Ted, hy others in this discussion,
>
> Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o:
>> Whether or not that will be acceptable upstream, I don't know, mainly
>> because I think a strong case can be made that such a patch has an
>> audience of one, and adding more complexity here for an idea which has
>> been time-tested over decades to be a failure is just not a good idea.
>
> I wouldn't tell the implementation until now to be a failure. It helped
> a lot to keep a system sane. It is true that all distributions ignored
> capabilities completely but I don't think that is due the design.
I think it's mostly due to the fact that there are a lot of potential
security issues in using capabilities as implemented in Linux (and other
POSIX systems), and unlike chroot(), it's not as easy to protect against
stuff trying to bypass them while still keeping them useful. If you do a
web search you can relatively easily find info on how to use many of the
defined capabilities to get root-equivalent access (CAP_SYS_ADMIN and
CAP_SYS_MODULE are obvious, but many of the others can be used also if
you know what you are doing, for example CAP_DAC_OVERRIDE+CAP_SYS_BOOT
can be used on non-SecureBoot systems to force the system to reboot into
an arbitrary kernel).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Di den 10. Nov 2015 um 14:19 schrieb Klaus Ethgen:
> + capable(CAP_ENABLE_AMBIENT)))
Should be !capable ...
As I wrote, I ask for comments and critics. The implementation is _not_
tested right now!
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWQfPjAAoJEKZ8CrGAGfas3+gMAMDjnusNAUBtzqh6mso/egX9
AhSeH7ps7rM0VtFzakZL1U2kz/ePuR9qGLvxjT/RpMEvcB1voV8SMj9ZJKlHLzbv
7J6eE4g8/X7hAo6I5J7n0DMyTVdt3me4Be5li5Kd2pL4amK8eocDc033XOSa/AYF
D3KXDxIrY2EzWHmh9zC/dGuZFdlLdvOZcoSdT6nLtE+AK0309fCubhyBvKn6rurZ
nRpJQnTCChnNXE7fcQodaXM8CRm19m3hYQey9TUj0nozSfFlHJ6UPAncLaoDp5n1
1PzEw/mJQdLzU8wbddVAOZSABluoP/wvCG3rvptgB6LqRSpjeEVkgNSdqfhuf5Af
gZ1ONX58cc+6ar7HImBCOyG82tD8b83d3p9XkP0YwIqFAIHpAbrXZKbMT+deS0Xa
BmbFBxFUv/hBi6ItdP9x5zM6yJn4FsKz5PM6281OZCeGSd4iRJvfAGZ8GpxzrGp1
RWto9qK6MkFjIhXDSxYktlYLeXb8bUiDIkL092Fcyg==
=koLI
-----END PGP SIGNATURE-----
On Tue, 10 Nov 2015, Theodore Ts'o wrote:
> If you want to create a patch, my recommendation would be to do one
> that turns off ambient capabilities as a CONFIG option, and hide it
> under CONFIG_EXPERT. Or maybe adding a new securebit which disables
> ambient capabilities. Whether or not that will be acceptable
> upstream, I don't know, mainly because I think a strong case can be
That is already available and was submitted with the patch.
commit 746bf6d64275be0c65b0631d8a72b16f1454cfa1
Author: Andy Lutomirski <[email protected]>
Date: Fri Sep 4 15:42:51 2015 -0700
capabilities: add a securebit to disable PR_CAP_AMBIENT_RAISE
Per Andrew Morgan's request, add a securebit to allow admins to disable
PR_CAP_AMBIENT_RAISE. This securebit will prevent processes from adding
capabilities to their ambient set.
For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather than
just disabling setting previously cleared bits.
Signed-off-by: Andy Lutomirski <[email protected]>
Acked-by: Andrew G. Morgan <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Serge Hallyn <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Aaron Jones <[email protected]>
Cc: Ted Ts'o <[email protected]>
Cc: Andrew G. Morgan <[email protected]>
Cc: Mimi Zohar <[email protected]>
Cc: Austin S Hemmelgarn <[email protected]>
Cc: Markku Savela <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: Michael Kerrisk <[email protected]>
Cc: James Morris <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Di den 10. Nov 2015 um 14:35 schrieb Austin S Hemmelgarn:
> On 2015-11-10 08:19, Klaus Ethgen wrote:
> >Hi Ted, hy others in this discussion,
> >
> >Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o:
> >>Whether or not that will be acceptable upstream, I don't know, mainly
> >>because I think a strong case can be made that such a patch has an
> >>audience of one, and adding more complexity here for an idea which has
> >>been time-tested over decades to be a failure is just not a good idea.
> >
> >I wouldn't tell the implementation until now to be a failure. It helped
> >a lot to keep a system sane. It is true that all distributions ignored
> >capabilities completely but I don't think that is due the design.
> I think it's mostly due to the fact that there are a lot of potential
> security issues in using capabilities as implemented in Linux (and other
> POSIX systems),
Well, of course. If you give a process capabilities, it can use it. That
is in the nature of the problem. But in comparison to SUID, it is
selective rights. That makes it much more troublesome to exploit. Why
the hell is, for example, ping installed SUID root? There is only one
privileged right that is needed instead of all or nothing.
> and unlike chroot(), it's not as easy to protect against stuff trying
> to bypass them while still keeping them useful.
It is the same, you have to be aware of the problem and need to mitigate
it.
chroot addresses different thinks than capabilities. And also chroot is
exploitable and you can break out in some cases. You have to do it
right...
> If you do a web search you can relatively easily find info on how to
> use many of the defined capabilities to get root-equivalent access
> (CAP_SYS_ADMIN and CAP_SYS_MODULE are obvious, but many of the others
> can be used also if you know what you are doing, for example
> CAP_DAC_OVERRIDE+CAP_SYS_BOOT can be used on non-SecureBoot systems to
> force the system to reboot into an arbitrary kernel).
Well, that is like it should be. If you give an exploitable application
rights that it should not have, it can get exploited. But this decision
is in the responsibility of the admin.
With ambient capabilities, you transfer that responsibilities to all the
different developers that once in a while wrote a SUID tool (or tool
with raised capabilities). So, tell me, where does the ambient
capabilities raise the security?
For the records: It does in limited cases when you start with all
capabilities and take away most except the one some sub tools needs.
But, sorry, I just sees that as a limited use. Nevertheless, for such
cases, ambient capabilities might be useful.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWQjBNAAoJEKZ8CrGAGfasvvUL/R/T1jG/gUV1N+8wYric3MvJ
T8do3YJUwaHId/1kOgL/FrS86LOchWSV7g8osWf6MZV0LToVrjUYKzUdsTlQ3Rdf
rYAegJG5hruWv2uWTe7v/ndzN1drg3q81hmCAx2c12bwJON1F03O7iCQEuJVWeP/
h9xYu1lIH37Pj36BEb/K5vCheTrdoQDGeAi/HcpmPmb0AfrSyYeNgrr6jcpvJnvm
aelyBt70MSymrwN2K4X8bPKSoheSZiW9Ol3dc6lLMWXbksX8tz5v2+8SeH38xETn
f0Ew1re12bxKRvK2XWzMQwHmEHTOhydWcIQjx+2Xu7M/l1YdevPRoENkCb/QmbZv
D3/fUNgtGU3fUPPzokSS6pqZyKHVNmPs767nPOAP0T/sPdwyMAP81LI/yspWJc7C
Tg1XqUSe9DUP3Dcejf+g7LqvimvErHAbJQ5OyubcFddOj4OeZhhbQZNnt60a1Fva
13zzZq7RQMIt9ZL/Hlqyx7pNXzw99fP0Mkfj93WyaQ==
=eUYZ
-----END PGP SIGNATURE-----
On 2015-11-10 12:58, Klaus Ethgen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Di den 10. Nov 2015 um 14:35 schrieb Austin S Hemmelgarn:
>> On 2015-11-10 08:19, Klaus Ethgen wrote:
>>> Hi Ted, hy others in this discussion,
>>>
>>> Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o:
>>>> Whether or not that will be acceptable upstream, I don't know, mainly
>>>> because I think a strong case can be made that such a patch has an
>>>> audience of one, and adding more complexity here for an idea which has
>>>> been time-tested over decades to be a failure is just not a good idea.
>>>
>>> I wouldn't tell the implementation until now to be a failure. It helped
>>> a lot to keep a system sane. It is true that all distributions ignored
>>> capabilities completely but I don't think that is due the design.
>> I think it's mostly due to the fact that there are a lot of potential
>> security issues in using capabilities as implemented in Linux (and other
>> POSIX systems),
>
> Well, of course. If you give a process capabilities, it can use it. That
> is in the nature of the problem. But in comparison to SUID, it is
> selective rights. That makes it much more troublesome to exploit. Why
> the hell is, for example, ping installed SUID root? There is only one
> privileged right that is needed instead of all or nothing.
FWIW, on Hardened Gentoo, ping is installed without the SUID bit set,
and has the appropriate fscaps attribute to give it CAP_NET_RAW. Sadly,
that's about the only tool that is set to use capabilities (the only
other one I know of is arping). Ping is however very purpose specific
and short of someone re-writing the binary, there really isn't much that
could be done to use it for privilege escalation. OTOH even when you use
capabilities, it's pretty easy for someone with a little shell scripting
knowledge to preform a DOS attack on a network just using ping.
>
>> and unlike chroot(), it's not as easy to protect against stuff trying
>> to bypass them while still keeping them useful.
>
> It is the same, you have to be aware of the problem and need to mitigate
> it.
>
> chroot addresses different thinks than capabilities. And also chroot is
> exploitable and you can break out in some cases. You have to do it
> right...
Again, this depends, there really isn't any way to make it impossible to
break out of a chroot without significant changes to the kernel, even
when using stuff like namespaces.
>
>> If you do a web search you can relatively easily find info on how to
>> use many of the defined capabilities to get root-equivalent access
>> (CAP_SYS_ADMIN and CAP_SYS_MODULE are obvious, but many of the others
>> can be used also if you know what you are doing, for example
>> CAP_DAC_OVERRIDE+CAP_SYS_BOOT can be used on non-SecureBoot systems to
>> force the system to reboot into an arbitrary kernel).
>
> Well, that is like it should be. If you give an exploitable application
> rights that it should not have, it can get exploited. But this decision
> is in the responsibility of the admin.
The big problem here is stuff like CAP_SYS_ADMIN and CAP_NET_ADMIN,
which group together a bunch of things that are only loosely related.
For example, both CAP_NET_ADMIN and CAP_NET_RAW include the ability to
bind to non-local addresses, but none of the stuff that I've ever seen
that uses CAP_NET_RAW instead of running as root uses that at all.
CAP_SYS_ADMIN includes a list of 24 different things that it allows,
many of which are themselves lists of other operations.
I'll try and dig up one of the better articles on this and post a link,
essentially, there are about a dozen capabilities that can be exploited
pretty easily to get root-equivalent access.
>
> With ambient capabilities, you transfer that responsibilities to all the
> different developers that once in a while wrote a SUID tool (or tool
> with raised capabilities). So, tell me, where does the ambient
> capabilities raise the security?
Unless you're personally auditing every single piece of code being run
on your system, you are inherently trusting the developers anyway.
On Tue, Nov 10, 2015 at 02:19:08PM +0100, Klaus Ethgen wrote:
> > And that's the fundamenal problem. Saying that you can only be secure
> > if **no** scripting languages can be used for **any** privileged
> > operations is something that _might_ work for you, but it doesn't work
> > for the 99.99999999999% of the Linux systems out there, many of which
> > have shell scripts to configure networking, or any host of other
> > things. Arguably, it's why Posix capalities have utterly failed as
> > far as usage except for a very, very, very, tiny, limited market.
>
> But this is use case 1 of two that I described earlier. And this is the
> main use case that is addressed by the ambient capabilities. I'm fine
> with that. That is nothing that I would object.
Actually, you did. To quote from an earlier message, "I would not
only say that it [administrative shell scripts running with privilege]
is avoidable, it is the worst that can happen." That's a pretty
strong objection in my book. And it's why discussing thing with you
is a bit frustrating.
> What I want to get fixed is the second use case of capabilities that was
> completely ignored by the design of ambient capabilities. It is about
> _raising_ explicitly single capabilities for _unprivileged_
> binaries/users.
That works fine with ambient capabilities. You can raise a single
capability with an unprivileged executable without any problems. The
problem is that you seem willing to trust that executable to have the
capability via an fscap setting, and not misuse it. *But* at the same
time you don't trust that executable to take an explicit set to allow
any of its children to use that executable. That's a wierd thing to
both simultaneously trust and distrust.
After all, suppose you give some process CAP_DAC_OVERRIDE, so it can
read any file on the system. How can you trust that it won't do
anything bad with that power? The only way you can do that is by
carefully auditing the code to make sure it won't do anything untoward
with that bit (either deliberately/maliciously or due to some
programming bug). If you are going to do that level of auditing, then
you can also check to make sure it's not trying to explicitly
manipulate the processes's capability mask to set the bit in the
ambient capability mask (which is just another malicious use of the
capability). Arguably, auditing this is much *less* effort than
making sure that the process isn't going to abuse CAP_DAC_OVERRIDE.
As far as complaint that you can't set securebits for the entire
system, sure you can. Just move /sbin/init to /sbin/init.real, and
replace /sbin/init with a program which sets
SECURE_NO_CAP_AMBIENT_RAISE and SECURE_NO_CAP_AMBIENT_RAISE_LOCKED,
and then exec's /sbin/init.real. Done! No kernel patch needed. :-)
- Ted
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Mi den 11. Nov 2015 um 3:04 schrieb Theodore Ts'o:
> On Tue, Nov 10, 2015 at 02:19:08PM +0100, Klaus Ethgen wrote:
> > > And that's the fundamenal problem. Saying that you can only be secure
> > > if **no** scripting languages can be used for **any** privileged
> > > operations is something that _might_ work for you, but it doesn't work
> > > for the 99.99999999999% of the Linux systems out there, many of which
> > > have shell scripts to configure networking, or any host of other
> > > things. Arguably, it's why Posix capalities have utterly failed as
> > > far as usage except for a very, very, very, tiny, limited market.
> >
> > But this is use case 1 of two that I described earlier. And this is the
> > main use case that is addressed by the ambient capabilities. I'm fine
> > with that. That is nothing that I would object.
>
> Actually, you did. To quote from an earlier message, "I would not
> only say that it [administrative shell scripts running with privilege]
> is avoidable, it is the worst that can happen." That's a pretty
> strong objection in my book. And it's why discussing thing with you
> is a bit frustrating.
Sorry, that I was misleading. I always told that in context of second
usecase. In the first usecase that is about reducing capabilities
instead of raising them, shells are already meant and used with all
rights.
The problem with shell scripts only (mostly) arise in the second
usecase.
I still keep my speaking that I will not object the first usecase.
> > What I want to get fixed is the second use case of capabilities that was
> > completely ignored by the design of ambient capabilities. It is about
> > _raising_ explicitly single capabilities for _unprivileged_
> > binaries/users.
>
> That works fine with ambient capabilities. You can raise a single
> capability with an unprivileged executable without any problems. The
> problem is that you seem willing to trust that executable to have the
> capability via an fscap setting, and not misuse it. *But* at the same
> time you don't trust that executable to take an explicit set to allow
> any of its children to use that executable.
Yes.
> That's a wierd thing to both simultaneously trust and distrust.
Particular, I trust nobody (not even myself sometimes). But giving
privileges is needed for some tasks. Ambient capabilities raise that to
a new level.
> After all, suppose you give some process CAP_DAC_OVERRIDE, so it can
> read any file on the system.
Particular, I would only give that capability (as the others) in
exchange to being SUID.
> How can you trust that it won't do
> anything bad with that power? The only way you can do that is by
> carefully auditing the code to make sure it won't do anything untoward
> with that bit (either deliberately/maliciously or due to some
> programming bug).
Right. I do that from time to time. But unfortunately my time is
limited.
So keep in mind, I use capabilities to _limit_ rights to the lowest set
that former had have SUID bit set.
> If you are going to do that level of auditing, then
> you can also check to make sure it's not trying to explicitly
> manipulate the processes's capability mask to set the bit in the
> ambient capability mask (which is just another malicious use of the
> capability).
Well, you audit one version. What if the developer sees: "Oh, there is
one new shiny thing in kernel, called ambient capabilities. Lets set
them to all my capabilities. That looks great", after you audited the
code..?
> Arguably, auditing this is much *less* effort than
> making sure that the process isn't going to abuse CAP_DAC_OVERRIDE.
No, auditing is hard work. And I simply have not the manpower to do it
for every tool for every new version. As I believe, nobody has.
> As far as complaint that you can't set securebits for the entire
> system, sure you can. Just move /sbin/init to /sbin/init.real, and
> replace /sbin/init with a program which sets
> SECURE_NO_CAP_AMBIENT_RAISE and SECURE_NO_CAP_AMBIENT_RAISE_LOCKED,
> and then exec's /sbin/init.real. Done! No kernel patch needed. :-)
Yea, that could work. But it is far more hacky than doing it right in
the kernel.
However, a kernel patch brought in that, in my eyes, security mess.
There was already an additional patch on request of Andrew Morgan. I
believe he had good reasons for asking for this. However, I don't see
where my objection is less serious than his apart the fact that he is a
well known kernel hacker and I am just a paranoid nobody.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWQxUEAAoJEKZ8CrGAGfasUtsL/jehWjS5u4IAUlOSGcoEM3zl
OJjA+Ez9CE6TGykkAwhJLlP3zmUsI/hn+09XNqSHFtezfycmp7tjRjWIsiNvb42Z
cMTpkUryBPpnOgrdZlr+YxmCyzO4jQs/5qly/MKBiR67GhquS0jlLKOWWRRT1Nkv
SpT8zEuGKB0O1SKY3FTKgSyxARA5eBNB4dqKYc7EFBYCWdPtYlOnDOMet+07dJp5
v7Acn506V0n30TztMQBIFovoX14yyT7nz/v3Td6yk6M7TxL8HXm2G4dDc2w/wPD7
msLEPTOS+WZ/M7DrYS8jIYwPGmW7as7FuOcPtjicGK9YBppEQJSygRHivxtUsD2b
TRrdD1TyPenPOWERg2DmbpHMyOyaydH09ZbE1EaMxYwW4yVHVUo5oMsjzQZNjvEJ
vv1ciZygaQe7c5uzVyMyHmrmuwtJn70tuPGB0boO4JnZgL6AvyVCqNyQ9aMU5OKc
OFvFdHxWnqiXHPjgBapevHVgUPKtTPV7q7vgUUyj7w==
=nf3o
-----END PGP SIGNATURE-----
On Wed, Nov 11, 2015 at 11:14:34AM +0100, Klaus Ethgen wrote:
> > If you are going to do that level of auditing, then
> > you can also check to make sure it's not trying to explicitly
> > manipulate the processes's capability mask to set the bit in the
> > ambient capability mask (which is just another malicious use of the
> > capability).
>
> Well, you audit one version. What if the developer sees: "Oh, there is
> one new shiny thing in kernel, called ambient capabilities. Lets set
> them to all my capabilities. That looks great", after you audited the
> code..?
But the developer can also change what files they look at; in fact,
they are *more* likely to make that kind of changes during the normal
course of development; not deliberately or maliciously, but as part of
adding a new feature to their program. If you don't have time to
audit to make sure they aren't using some new capability feature
(which you can do using the simple application of "grep"), you don't
have time to audit to make sure they haven't changed something which
will cause their use of CAP_DAC_OVERRIDE to be dangerous.
Which is why I maintain it is very wierd that you are paranoid about
the first concern, but are blithely unconcerned about the second,
which is more likely. And it is *because* you are the one who have
this extremely strange and selective paranoia, and most other people
won't, it seems fair (to me) that you are the one that has to pay the
extra cost of working around the problem. After all, if you're this
paranoid, you must building all of your binaries from scratch, too.
(Or else you have to trust lots of package maintainers or distro
release engineers. I'll remind you that some of the more catastrophic
security problems have come from Debian maintainers, some of which
made patches in code they didn't completely understand, and which had
nothing to do with elevated privileges.) So the cost of patching init
to set the securebit should be in the noise for you.
Cheers,
- Ted
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am Mi den 11. Nov 2015 um 11:54 schrieb Theodore Ts'o:
> On Wed, Nov 11, 2015 at 11:14:34AM +0100, Klaus Ethgen wrote:
> > > If you are going to do that level of auditing, then
> > > you can also check to make sure it's not trying to explicitly
> > > manipulate the processes's capability mask to set the bit in the
> > > ambient capability mask (which is just another malicious use of the
> > > capability).
> >
> > Well, you audit one version. What if the developer sees: "Oh, there is
> > one new shiny thing in kernel, called ambient capabilities. Lets set
> > them to all my capabilities. That looks great", after you audited the
> > code..?
>
> But the developer can also change what files they look at; in fact,
> they are *more* likely to make that kind of changes during the normal
> course of development; not deliberately or maliciously, but as part of
> adding a new feature to their program. If you don't have time to
> audit to make sure they aren't using some new capability feature
> (which you can do using the simple application of "grep"), you don't
> have time to audit to make sure they haven't changed something which
> will cause their use of CAP_DAC_OVERRIDE to be dangerous.
>
> Which is why I maintain it is very wierd that you are paranoid about
> the first concern, but are blithely unconcerned about the second,
> which is more likely. And it is *because* you are the one who have
> this extremely strange and selective paranoia, and most other people
> won't, it seems fair (to me) that you are the one that has to pay the
> extra cost of working around the problem. After all, if you're this
> paranoid, you must building all of your binaries from scratch, too.
>
> (Or else you have to trust lots of package maintainers or distro
> release engineers.
All right.
The only thing you can do is to do all you can. And lowering SUID use to
selective capability use is one important step in that direction.
There is no way to have a all secure system. You can only do the most
possible.
Nevertheless, I object a _new_ feature that brings some security
concernes. So it is not uncommon, to work on that.
> I'll remind you that some of the more catastrophic
> security problems have come from Debian maintainers, some of which
> made patches in code they didn't completely understand, and which had
> nothing to do with elevated privileges.)
Thats true. For example openssh patching debacle just to support some
accomodativeness on the cost of security. Upstream refused that patch
but they still have it in debian. That was when I did start packaging my
own openssh package in my own "debian-security" repository. However,
that is a single package (in fact, I have a few there). With every
package that has to be fixed the load goes more in the direction of not
being capable anymore to handle it.
Also that discussion here is, especially from the fact that english is
not my main language, time-consuming. But I was thinking (and still
hope) that kernel developers are not that stupid than some debian
maintainers. I still hope that they are not so stubborn to ignore a
use-case that is already used by some out there and only focusing on a
use-case that is used nowhere.
> So the cost of patching init to set the securebit should be in the
> noise for you.
As it is to provide a patch that does it right. (As I did already.)
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <[email protected]>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJWQyLcAAoJEKZ8CrGAGfasSH0L/1NLo4fxZoEL1PNDCKCcmlUW
8h3ThJhdNQqu8xRl47Q6RW/K7tv0My/blihNZEzIn6ssmTXd8JIlP3uHfz+XA2aZ
FbduAc2KOoW8H1ItYbWL4hnJq94/Pvp+0vOBMSG+fKL/09A8X8RmiAiCsnX6Eirl
64WCk1dyDILWPpkQ0w7XKy4DA69AX7DSBLpYCANwOsFzIZR0Npx3VinF55kVHE53
9g3x8+NifOLJ3qPkSwUg+U86AOWlQhnsI3EQJYwJ+WLnkrHEoKHvBlDDRqfNMoRK
c1IqgD9ISnjPf1PO+MQ2CQ0kE8VdTXNaZKU4PvFFzJJE1iAa2SgJjY/tXLgmHaQ/
RCs6RoJkZ/8VbpmOFcALNJuIIWjaG6GUii296MnvYPE2VnJXQ3NoUDsRlmA5jRBA
klmbWAOz5pBknx5AE8zjgAyHQ/trpNxHnW+OBtfhxqoohTIZJxHIDxZD6MuSNVVs
dw9MJf/pR6T4xN70H9oFG7eb7Ic3E92IFkSsM9Vvng==
=P+pQ
-----END PGP SIGNATURE-----