On Thu, 2005-01-20 at 11:21 -0500, Stephen Smalley wrote:
> On Thu, 2005-01-20 at 11:19, Colin Walters wrote:
> > Right; but studying the policy a bit more, there are definitely
> > permissions given to CGI scripts not given to ordinary userdomains,
> > e.g.:
> >
> > ############################################
> > # Allow scripts to append to http logs
> > #########################################
> > allow httpd_$1_script_t httpd_log_t:file { getattr append };
>
> Append-only access should be relatively benign, although I'm not sure
> whether it is justified here. But if it allowed to httpd_user_script_t,
> then user_t effectively has those permissions anyway, as he can always
> create a CGI script with arbitrary code and then access the URL to
> invoke it from httpd, whether or not he can directly transition to the
> domain or not.
Agreed; I was bringing this up primarily to point out that simply
removing the automatic transition would introduce other issues. I have
a feeling that there's another issue having to do with preserving file
contexts, but I can't put my finger on it.
> > So that's something to consider. Perhaps what we really want is a
> > domain derived from httpd_$1_script_t, e.g. httpd_$1_test_script_t,
> > which is allowed to write to the terminal as well. That would be fairly
> > complex though...
>
> Could certainly be done via shared macros for these testing domains and
> the normal script domain. But not clear it is worth it...
Yeah. It might be nice if the policy language had an easy "subclass"
mechanism. That's a whole other topic though...
For now anyways, we could probably just change it to a domain_trans; a
quick look at the policy seems to show the httpd_log_t access being the
only obvious additional permission granted. Presumably a majority of
setups with CGI scripts and users are using suEXEC and do not allow
ordinary uids any kind of write access to the main httpd logs.
