linux-kernel - Kernel 4.3 breaks security in systems using capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Nov 2015 19:06:25 +0100
From:	Klaus Ethgen <Klaus+lkml@...gen.de>
To:	linux-kernel@...r.kernel.org
Subject: Kernel 4.3 breaks security in systems using capabilities

-----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@...gen.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/