On 2016-03-03 12:22, Jim Jagielski wrote:
I still don't understand what your actual concern is, nor
the attack vector that you are trying to fix. Can you
provide more detail, being as specific as possible.
Thx.
Let me clarify the problem by changing it very slightly:
a) What are the implications of /usr/sbin/suexec being owned by
apache:apache?
- As the owner of its own binary, a bug or exploit could modify it
without escalation.
b) What are the implications of /usr/sbin/suexec refusing to run when
NOT owned by apache:apache?
- Barring nonstandard features, it can't be meaningfully secured.
Which is why apache demands that it NOT own suexec:
-rws--x--- 1 root apache 14120 Feb 26 17:58 /usr/sbin/suexec
Even if the kernel would be okay with other ownership, suexec will freak
out. This arrangement prevents anything but a sever escalation bug from
altering the suexec executable.
Once past this gate and seduid-ed, though, suexec insists upon
user-owned files inside user-owned filers. I suppose this slightly like
a chmod jail -- you can trash your own files and folders, but at least
you won't trash anyone else's. But I don't see why this setup is
mandatory -- it could be secured much further.
In short: suexec requiring files belong to a specific owner and group
makes sense to avoid blank-cheque situations, but why insist on BEING
that owner too? That guarantees a different blank-cheque situation.
