On Thu, 17 May 2012 16:20:40 -0400 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On May 17, 2012, at 4:11 PM, Jeff Layton wrote: > > > On Thu, 17 May 2012 14:52:58 -0400 > > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > >> > >> On May 17, 2012, at 1:54 PM, Jeff Layton wrote: > >> > >>> statd drops all capabilities except for CAP_NET_BIND when it starts. It's > >>> possible though that if it ever had a compromise that an attacker would be > >>> able to invoke a setuid process (or something with file capabilities) in > >>> order to reinstate some caps. > >>> > >>> This could happen as a result of the daemon becoming compromised, or > >>> possibly as a result of the ha-callout program becoming compromised. > >> > >> Generally, I wonder what our exposure to this attack for a statd built without capability support. Just musing out loud. > >> > > > > It is difficult to qualify this without a specific attack in mind. The > > story I've always gotten from those who work with capabilities for a > > living however is that unless you prune the bounding set, the job isn't > > complete. > > My question was muddled. I'll try again. If statd is built with "--disable-caps", then I think statd won't drop capabilities at all. Are we agreeing that nothing can be done in that case to mitigate this kind of attack? > Probably not... If a build specifies --disable-caps, then I take that to mean that it shouldn't try to do anything with capabilities. I see that increased exposure as the price you pay for not building against libcap. Given that, I'll ensure that we don't attempt to modify the bounding set too in that case... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
