linux-kernel - Re: capget() overflows buffers.

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48366D9A.70806@kernel.org>
Date:	Fri, 23 May 2008 00:09:14 -0700
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Chris Wright <chrisw@...s-sol.org>
CC:	Dave Jones <davej@...emonkey.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	bojan@...ursive.com, "Serge E. Hallyn" <serue@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Security Modules List 
	<linux-security-module@...r.kernel.org>
Subject: Re: capget() overflows buffers.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Wright wrote:
|> The kernel is not crashing, the application is...
|
| It's not about crashing.  It's about app security.  Currently, there is
| nothing guaranteeing named has actually dropped privileges.  That's why
| I consider this serious.

I have to say the details of this are not clear to me. Can you sketch an
example?

Otherwise, I find myself generally persuaded..

| Yes, as they should.  I don't think we should ever expect an existing
| userspace program change just by recompiling against a new kernel header
| when using an already existing mechanism.  Their app has been working
| fine since 2.2.
|
|   int fd = open("foo", O_FLAGS, mode);
|
| compile once...binary compatible going forward (as is cap{s,g}et).
| update kernel, recompile...source API comaptible...still working
| (this is broken in cap{s,g}et).

[I guess that this was what libcap was all about, and why there are so
many comments about using it littered through the kernel... Oh well.]

| History bites us...libcap wasn't always there.  As we see, people roll
[...]

Not to pick holes in your argument, but libcap *has* always been there.
It was co-developed with the original kernel patches.

| No, the solution there would be to keep _LINUX_CAPABILITY_VERSION as
| v1 (otherwise you just broke apps again).  And use another mechanism to
| signal the availability of 64bit caps.

Point taken. Patch attached.

Cheers

Andrew

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFINm2Z+bHCR3gb8jsRAmDJAJ9rm3W9wKqA9EBuUVCyccZJDy6XvACgkbqp
noq663WjGQFVe94VsjkOZYY=
=x9NL
-----END PGP SIGNATURE-----

View attachment "remain-source-compatible-with-32-bit-raw-legacy-capa.patch" of type "text/plain" (5816 bytes)