Re: Suexec permissions question

[mo...@heavyspace.ca]

On 2016-02-29 10:22, monttyle@heavyspace.ca wrote:
> On 2016-02-29 06:06, Jim Jagielski wrote:
>>> On Feb 26, 2016, at 7:50 PM, monttyle@heavyspace.ca 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.