On 2016-02-29 10:22, [email protected] wrote:
On 2016-02-29 06:06, Jim Jagielski wrote:
On Feb 26, 2016, at 7:50 PM, [email protected] wrote:
This is not a question on how to use suexec, that's fairly clear.
The strict, hardwired conditions its willing to suexec under are also
spelled out pretty clear. My question is the nature of these
requirements -- why they're the way they are. The user and group
requirements specifically.
suexec insists that the file being executed needs to be the same
owner and group as what the web server will be running as after
suexec. Doesn't this requirement make things *less* secure? You
can't really protect a file against its own owner overwriting it.
The same requirement is on the folder, leaving the web server two
legal chmods away from allowing an exploit to create, delete, and
modify files inside the vhost at will.
Those conditions are hardly unique. The other major suexec-like
script, cgiwrapd, also had the same set of conditions and
requirements.
First of all, the idea is that the admin "trusts" whatever users are
allowed to use suexec. It's also understood that the risk associated
is directly related to how well tied-down the user account itself
is. Finally, it's to ensure that when running as 'foo:bar", I can
only access files that are owned by 'foo:bar'. If I am 'foo:bar'
and I am trying to run a file owned by 'kirk:trek' then something
is hinky, and we don't want to allow it.
I understand the point of not allowing apache to suexec any
arbitrary file, and matching user:group makes sense to an extent.
But using user:group as blind labels ignores what these permissions
really mean to the kernel.
Any running program has access to modify any files and folders
belonging to its user by definition. If you chmod that away,
it can chmod them right back. This is very difficult to prevent
without resorting to read-only filesystems, immutable bits, or
ACL's. This is why most executables -- including suexec itself!
-- aren't owned by the users who run them.
The ability to name a specific required owner, DIFFERENT from
what's being suexec-ed to, would close this security hole.
Any comments? I am considering writing that patch if I can,
but there may be pitfalls I haven't thought of.
