For historical purposes :)
[13:25:42] <jchampion> jimjag: I'll let monttyle respond on-list, but his attack vector (at least, as I understood it) was as follows: [13:26:39] <jchampion> 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] <jchampion> 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] <jchampion> (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] <jchampion> 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] <jchampion> "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] <jchampion> CGI app A runs under "jimA", app B runs under "jimB", etc. [13:30:00] <jchampion> that way app A can touch its own stuff, but not app B's stuff. [13:30:04] <jchampion> and vice-versa. [13:30:25] <@jimjag> but jima and jimb would need to be different uids, right? [13:30:29] <jchampion> 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] <jchampion> 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] <jchampion> 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] <jchampion> 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] <jchampion> 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] <jchampion> 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] <jchampion> 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] <thumbs> 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] <jchampion> jimjag: setuid scripts are verboten in the security sphere, for one [13:39:29] <jchampion> 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] <jchampion> 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] <jchampion> 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] <jchampion> if they are root. Remember, his use case is an administrator separating concerns between multiple administrator-owned applications. [13:42:26] <jchampion> 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] <jchampion> It's just one "person" here, using suexec for privilege separation. [13:43:32] <jchampion> 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] <jchampion> Whether the users are real people or just system accounts. [13:44:00] <jchampion> 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] <jchampion> In other words: if you designed a tool to do this "new thing", it would end up duplicating all of suexec, and adding a single new feature. [13:45:21] <@jimjag> jchampion : How? Most of the checks, etc are based on a specific use case that no longer applies in this one, if I grok it... [13:45:52] <jchampion> AFAICT, all of the checks still apply, to avoid setuid vulnerabilities. There's only one that is changed: the check for ownership. [13:46:40] <jchampion> The vast majority of the suexec logic is there to avoid setuid attacks. All of that would be duplicated. [13:47:10] <@jimjag> I'd have to see the implementation...
