User: Password:
|
|
Subscribe / Log in / New account

Expanding seccomp

Expanding seccomp

Posted May 11, 2011 19:59 UTC (Wed) by Baylink (guest, #755)
Parent article: Expanding seccomp

Well, this is all good cheese... but as someone who's spent the larger part of my career as a sysadmin rather than a programmer... *I can't see into it*.

SUID is pretty easy to audit. Capabilities, though I haven't used them much, are -- so I gather -- similar to audit from the sysadmin viewpoint.

This is going to affect security *down inside the source code where I can't see it*, is it not? Now, sure, it *reduces* the things a process can do.

But from what? If this *expands* the universe of stuff I gotta audit *because it inspires people to require more capabilities than they really need, and then drop the stuff they don't want... then it's going to make sysadmins' lives harder.


(Log in to post comments)

Expanding seccomp

Posted May 11, 2011 20:48 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> But from what? If this *expands* the universe of stuff I gotta audit *because it inspires people to require more capabilities than they really need, and then drop the stuff they don't want... then it's going to make sysadmins' lives harder.

I don't really see the problem. Before file capabilities, if a process required *any* extra capabilities it needed to be SUID to root. Now processes can start out with a subset of those capabilities rather than full SUID. Worst case, I would think you could simply treat any executable file with a non-empty set of file capabilities as if it were SUID.

Or are you concerned that people will add individual capabilities to programs that formerly didn't require any, where the stigma of requiring full SUID would have dissuaded them?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds