> On the other hand, I have this suspicion that the most secure setup is one
> that the sysadmin is _used_ to, and knows all the pitfalls of. Which
> obviously is a big argument for just maintaining the status quo with suid
> binaries.
>
> We have decades of knowledge on how to minimize the negative impact of
> suid (I've used sendmail as an example of a suid program, and yet last I
> looked sendmail was actually pretty careful about dropping all unnecessary
> privileges very early on).
Quite so. Now, ability to _remove_ capabilities on exec() is a Good Thing(tm)
regardless of suid. It can be combined with suid - that gives you something
that is still evil, but less than it used to be. But I don't see any point
in new independent mechanism for raising caps - e.g. since it assumes a
bunch of new programs that were written to run with elevated caps and
with assumption that they will be less dangerous than suid-root ones.
Somehow, it doesn't make me happy about running such programs - not for
first 5 years or so.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/