Re: Suexec permissions question
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.
Re: Suexec permissions question
I think this can be summarized as follows; Httpd starts as root, changes to httpd user account. AppDev user account is compiled-in to suexec as run-if-owner matches that user account. Suexec invokes AppDev's script with the appropriate userid of AppRun account in lieu of AppDev user. AppRun user has no permission to manipulate AppDev owned applications. Suexec will refuse to run applications owned by AppRun account itself.
Re: Suexec permissions question
For historical purposes :) [13:25:42] jimjag: I'll let monttyle respond on-list, but his attack vector (at least, as I understood it) was as follows: [13:26:39] attacker uses a one-time vulnerability in a CGI script to modify the script itself (or anything in the parent directory) and thus becomes a persistent threat [13:27:30] if suexec allowed a separate owner (for example, root), this wouldn't be possible, as long as the parent directory and executable script were root-owned. [13:27:51] (he wanted to be able to specify a different trusted owner for maintenance purposes) [13:28:26] <@jimjag> jchampion : well, if I grok that right, then why even use suexec at all? [13:28:47] jimjag: to isolate several CGI apps running under different trust levels. [13:28:47] <@jimjag> let the person run their CGI script as the web server uid [13:29:12] "user" here isn't "person"; he's essentially separating them into different system accounts [13:29:22] <@jimjag> So how would that work. I am 'jim' but my CGIs run as 'jimfoo' ?? [13:29:37] niq (~God@apache/committer/niq) left IRC (Ping timeout: 252 seconds) [13:29:43] CGI app A runs under "jimA", app B runs under "jimB", etc. [13:30:00] that way app A can touch its own stuff, but not app B's stuff. [13:30:04] and vice-versa. [13:30:25] <@jimjag> but jima and jimb would need to be different uids, right? [13:30:29] yes. [13:31:33] <@jimjag> So what is to prevent someone from someone using the above one-time vulnerability in a CGI script as jimB and thus continue to be a threat? [13:32:36] The answer to that is app-specific, I think. monttyle's point is that the current suexec strategy forces at least two points of vulnerability (the parent directory and the script itself) [13:33:18] <@jimjag> So the App is owned by a different uid that the app runs as?? [13:34:01] the app's executable is, yes. The rest of the "app" may be assets, databases, whatever, that are owned by the UID that the app is running as. [13:34:20] Those assets could be locked down to limit the damage that a bad-acting jimB could do, for instance. [13:35:17] <@jimjag> So I create an app, owned by me, which the runs as say jchampion, which then has access to all of jchampions files on the file system ? :) [13:36:22] no, because 1) you don't have permission to modify the Apache config to do that, and 2) the owner must be explicitly trusted (at compile-time) in monttyle's suggested scheme. [13:37:01] in other words, he's asking for a "I trust user X, so let it own a suexec'd file, but no one else" [13:37:57] personally, I think it'd be enough of a compromise to add a root-ownership exception. But I see where he's coming from on the maintenance side. [13:38:12] interesting [13:38:17] <@jimjag> so why can't the admin just create a cgi-script that itself is suid to whoever they want that user to "pretend" to be? [13:39:03] <@jimjag> It sounds like it's a whole diferent use case thansuexec [13:39:12] jimjag: setuid scripts are verboten in the security sphere, for one [13:39:29] for two, they'd have to become a setuid security expert to do it correctly [13:39:58] <@jimjag> suexec is designed for a singlular specific purpose... adding "features" to it increases the attack vector surface area... :) [13:40:26] I agree with you there, which is why I'm for a middle ground that allows root ownership in the check. [13:40:34] <@jimjag> I'm not opposed to the feature, but adding it to suexec seems wrong, imo at least. [13:41:10] i.e. if the parent directory and the CGI script are owned by root instead of the suexec'ing user, that should be okay too. [13:41:38] <@jimjag> how in the world would someone be able to update the script if owned by root? [13:42:08] if they are root. Remember, his use case is an administrator separating concerns between multiple administrator-owned applications. [13:42:26] It's a different use case from the typical "I have a bunch of end users who want to run stuff on port 80" [13:43:01] <@jimjag> But again, that seems opposite from what suexec is all about. It's all about USERS, not the admin. [13:43:03] It's just one "person" here, using suexec for privilege separation. [13:43:32] How would you solve the problem then? suexec seems like a perfect tool for privilege separation. [13:43:46] <@jimjag> So yeah, it's a different use case, which requires a different solution, not "extending" an existing solution for a specific use-case... if you catch my meaning [13:43:47] Whether the users are real people or just system accounts. [13:44:00] But suexec is already a privilege separation tool... [13:44:12] <@jimjag> So like I said, I'm fine w/ the concept; just not fine with it being folded into suexec. [13:44:29] <@jimjag> I don't want suexec to turn into systemd :) [13:44:37] In other words: if you designed a tool to do this "new thing", it
Re: Suexec permissions question
> On Feb 29, 2016, at 11:22 AM, montt...@heavyspace.ca wrote: > > 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. No, it's meant to work *with* file-level permissions. > > 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. 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.
Re: Suexec permissions question
On 2016-02-29 10:22, montt...@heavyspace.ca wrote: On 2016-02-29 06:06, Jim Jagielski wrote: On Feb 26, 2016, at 7:50 PM, montt...@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.
Re: Suexec permissions question
On 2016-02-29 06:06, Jim Jagielski wrote: 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. It's more of a first-past-the-door situation. By definition, any suexec-ed file will have at least one daemon-modifiable executable, and one daemon-modifiable folder available to be exploited. That's taking "trust" farther than strictly necessary.
Re: Suexec permissions question
On 2016-02-29 06:06, Jim Jagielski wrote: On Feb 26, 2016, at 7:50 PM, montt...@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.
Re: Suexec permissions question
> On Feb 26, 2016, at 7:50 PM, montt...@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.
Suexec permissions question
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.
