Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1260848 > unrolled thread

Kernel 4.3 breaks security in systems using capabilities

Back to article view | Back to linux.kernel

Contents

  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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1264809 — Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.de>
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-----
--
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]

#1265136 — Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

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)
--
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]

#1265832

[Multipart message — attachments visible in raw view] — view raw

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).

[toc] | [prev] | [next] | [standalone]

#1265882 — Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1265953 — Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1266030 — Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1266096 — Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

On Nov 9, 2015 1:29 PM, "Klaus Ethgen" <Klaus+lkml@ethgen.de> 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 <Klaus@Ethgen.ch>
> 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-----
--
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]

#1266440 — Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1266472 — Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

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.
--
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]

#1266481 — Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

[Multipart message — attachments visible in raw view] — view raw

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 <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

[toc] | [prev] | [next] | [standalone]

#1266500 — Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

[Multipart message — attachments visible in raw view] — view raw

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).

[toc] | [prev] | [next] | [standalone]

#1266689 — Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1266776 — Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1266512 — Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1266924 — Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

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
--
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]

#1267081 — Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1267103 — Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

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
--
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]

#1267110 — Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

-----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 <Klaus@Ethgen.ch>
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-----
--
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]

#1266572 — Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

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 <luto@kernel.org>
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 <luto@kernel.org>
    Acked-by: Andrew G. Morgan <morgan@kernel.org>
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Serge Hallyn <serge.hallyn@canonical.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Aaron Jones <aaronmdjones@gmail.com>
    Cc: Ted Ts'o <tytso@mit.edu>
    Cc: Andrew G. Morgan <morgan@kernel.org>
    Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
    Cc: Markku Savela <msa@moth.iki.fi>
    Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

--
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]

#1263404 — Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

On Thu, Nov 5, 2015 at 2:19 AM, Klaus Ethgen <Klaus+lkml@ethgen.de> 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
--
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 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web