Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1260848 > unrolled thread
| Started by | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| First post | 2015-11-02 19:10 +0100 |
| Last post | 2015-11-05 18:30 +0100 |
| Articles | 20 on this page of 41 — 9 participants |
Back to article view | Back to linux.kernel
Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-02 19:10 +0100
Re: Kernel 4.3 breaks security in systems using capabilities Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-02 19:40 +0100
Re: Kernel 4.3 breaks security in systems using capabilities Andy Lutomirski <luto@amacapital.net> - 2015-11-02 20:00 +0100
Re: Kernel 4.3 breaks security in systems using capabilities Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-02 20:00 +0100
Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-02 20:20 +0100
Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Andy Lutomirski <luto@amacapital.net> - 2015-11-02 20:50 +0100
Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-05 11:30 +0100
Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-05 17:20 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-05 18:20 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-05 18:40 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-05 18:50 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Andy Lutomirski <luto@amacapital.net> - 2015-11-05 20:10 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-05 23:10 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-06 15:00 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Theodore Ts'o <tytso@mit.edu> - 2015-11-06 17:00 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Andy Lutomirski <luto@amacapital.net> - 2015-11-06 18:20 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Casey Schaufler <casey@schaufler-ca.com> - 2015-11-06 19:00 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-06 19:10 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-06 19:00 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-06 19:20 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-07 12:10 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-08 18:10 +0100
Re: Kernel 4.3 breaks security in systems using capabilities Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-09 17:40 +0100
Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-09 18:30 +0100
Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-09 20:10 +0100
Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-09 22:30 +0100
Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Andy Lutomirski <luto@amacapital.net> - 2015-11-10 01:10 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-10 13:00 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Theodore Ts'o <tytso@mit.edu> - 2015-11-10 13:50 +0100
Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-10 14:20 +0100
Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-10 14:40 +0100
Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-10 19:10 +0100
Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-10 21:50 +0100
Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-10 14:50 +0100
Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Theodore Ts'o <tytso@mit.edu> - 2015-11-11 03:10 +0100
Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-11 11:20 +0100
Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Theodore Ts'o <tytso@mit.edu> - 2015-11-11 12:00 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-11 12:20 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Christoph Lameter <cl@linux.com> - 2015-11-10 16:30 +0100
Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Andy Lutomirski <luto@amacapital.net> - 2015-11-05 17:30 +0100
Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen <Klaus+lkml@ethgen.de> - 2015-11-05 18:30 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-02 19:10 +0100 |
| Subject | Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qqrIn-7E-11@gated-at.bofh.it> |
-----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 <Klaus@Ethgen.de> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Richard Weinberger <richard.weinberger@gmail.com> |
|---|---|
| Date | 2015-11-02 19:40 +0100 |
| Message-ID | <qqsbn-hk-3@gated-at.bofh.it> |
| In reply to | #1260848 |
CC'ing patch authors. On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <Klaus+lkml@ethgen.de> 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 <Klaus@Ethgen.de> > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-11-02 20:00 +0100 |
| Message-ID | <qqsuK-nX-7@gated-at.bofh.it> |
| In reply to | #1260862 |
On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger <richard.weinberger@gmail.com> wrote: > CC'ing patch authors. > > On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <Klaus+lkml@ethgen.de> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-11-02 20:00 +0100 |
| Message-ID | <qqsuK-nX-9@gated-at.bofh.it> |
| In reply to | #1260862 |
On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger
<richard.weinberger@gmail.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-02 20:20 +0100 |
| Subject | Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qqsO6-JS-15@gated-at.bofh.it> |
| In reply to | #1260884 |
-----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 <Klaus@Ethgen.de> 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-11-02 20:50 +0100 |
| Subject | Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qqth7-VK-15@gated-at.bofh.it> |
| In reply to | #1260898 |
On Mon, Nov 2, 2015 at 11:16 AM, Klaus Ethgen <Klaus+lkml@ethgen.de> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-05 11:30 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrpXQ-5kx-39@gated-at.bofh.it> |
| In reply to | #1260916 |
-----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 <Klaus@Ethgen.de> 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2015-11-05 17:20 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrvqA-ys-65@gated-at.bofh.it> |
| In reply to | #1263079 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-05 18:20 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrwmB-19U-3@gated-at.bofh.it> |
| In reply to | #1263390 |
-----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 <Klaus@Ethgen.de> 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2015-11-05 18:40 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrwFY-1gt-19@gated-at.bofh.it> |
| In reply to | #1263437 |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-05 18:50 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrwPD-1jX-7@gated-at.bofh.it> |
| In reply to | #1263450 |
-----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 <Klaus@Ethgen.de> 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-11-05 20:10 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qry55-2hu-41@gated-at.bofh.it> |
| In reply to | #1263454 |
On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <Klaus+lkml@ethgen.de> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2015-11-05 23:10 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrATh-44X-23@gated-at.bofh.it> |
| In reply to | #1263490 |
On Thu, Nov 05, 2015 at 11:01:07AM -0800, Andy Lutomirski wrote: > On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <Klaus+lkml@ethgen.de> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-06 15:00 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrPID-5cI-23@gated-at.bofh.it> |
| In reply to | #1263576 |
-----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 <Klaus+lkml@ethgen.de> 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 <Klaus@Ethgen.de> 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| Date | 2015-11-06 17:00 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrRAK-6pR-11@gated-at.bofh.it> |
| In reply to | #1264032 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-11-06 18:20 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrSQ9-7p7-11@gated-at.bofh.it> |
| In reply to | #1264111 |
On Fri, Nov 6, 2015 at 7:53 AM, Theodore Ts'o <tytso@mit.edu> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Casey Schaufler <casey@schaufler-ca.com> |
|---|---|
| Date | 2015-11-06 19:00 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrTsS-7CR-17@gated-at.bofh.it> |
| In reply to | #1264111 |
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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2015-11-06 19:10 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrTCx-7VU-7@gated-at.bofh.it> |
| In reply to | #1264201 |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Ethgen <Klaus+lkml@ethgen.de> |
|---|---|
| Date | 2015-11-06 19:00 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrTsS-7CR-23@gated-at.bofh.it> |
| In reply to | #1264111 |
-----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 <Klaus@Ethgen.de> 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2015-11-06 19:20 +0100 |
| Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| Message-ID | <qrTMe-80j-17@gated-at.bofh.it> |
| In reply to | #1264202 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.kernel
csiph-web