Subject: [PATCH] security: was "Re: capget() overflows buffers."
Date: Tuesday 27th May 2008 01:17:15 UTC (over 10 years ago)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Wright wrote: | * Andrew G. Morgan ([email protected]) wrote: |> Your concern is for the situation when the garbage happens to correspond |> to an apparently meaningful setting for the upper capability bits? The |> problem being that this privileged application is more privileged than |> intended? I agree that this is not ideal. | | Yep, exactly. | |> In practice, however, this is only a real problem if named (or a |> similarly structured program) has a security related bug in it. No? | | It's dropped privileges to help mitigate any security related bug it | may contain. It's conceivable (albeit remote) that fork/exec plus | inheritable could leak privs w/out a security related bug. | |> Is this your concern, or have I missed something? | | That's it. OK, so by way of summary, the kernel, per se, is *not* broken, but the kernel include file is problematic for use by user space - ie., having used it some recompiled programs may be subtly broken... [ Example, https://bugzilla.redhat.com/show_bug.cgi?id=447518 ] Basically I agree that we should err on the side of being conservative... | thanks, | -chris | |  Get lucky combo in the garbage bits and have not shed uid 0. | Much less likely. So far as I can tell, the two problems (for unprepared applications - not using libcap etc.) are: ~ 1. what the capget() system call may be writing to data may lead to unpredictable reliability issues with the security of the running program (when its only allocated space for data). ~ 2. the garbage that the capset() system call may be setting in pI that persists post-exec(). The security issue being (in the case that the system has been configured with filesystem capability support) the leak of inheritable bits that become effective through the subsequent invocation of a filesystem-capable (fI != 0) application. The net result being that this subsequent application gives capabilities to a user that shouldn't wield them. How about the attached for a combined patch? Chris, the only change over last time is basically your suggested code change, with more comments and a less cautious warning... Cheers Andrew Ref: patch: 0c736c9f0ab16899df1803d5962287985e69a157 and libcap-2.10 supports this change. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFIO2Ea+bHCR3gb8jsRAowdAJ9kMa15tXLyv6t1EfV0pyOsbqk49QCgsjRJ +SCiUsbN7M5nfdehXBWjzt0= =Ri1u -----END PGP SIGNATURE-----