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

[Andy Lutomirski]

On Nov 9, 2015 1:29 PM, "Klaus Ethgen" <Klaus+lkml@xxxxxxxxx> 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@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/