You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2017/03/31 00:51:35 UTC
[Bug 60946] New: "Require not env" generates error
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
Bug ID: 60946
Summary: "Require not env" generates error
Product: Apache httpd-2
Version: 2.4.25
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_authz_host
Assignee: bugs@httpd.apache.org
Reporter: philipp@redfish-solutions.com
Target Milestone: ---
If you can have an affirmative test like:
<Location />
Require env is_good_request
</Location>
you should also be able to have:
<Location />
Require not env is_bad_request
</Location>
but apparently this isn't allowed. It results in the error:
Mar 28 14:04:49 mail httpd[2964]: AH00526: Syntax error on line 81 of
/etc/httpd/conf.d/mod_setenvif.conf:
Mar 28 14:04:49 mail httpd[2964]: negative Require directive has no effect in
<RequireAny> directive
which for many is a meaningless message.
Getting security right should be as painless and straightforward as possible.
Unfortunately, that's not the case here.
I had to instead do:
<Location />
<RequireAll>
Require all granted
Require not env is_bad_request
</RequireAll>
</Location>
but this, again, is less than obvious. So I ended up rewriting my
configuration as a positive assertion, but that too is awkward:
SetEnvIfExpr true is_good_request=1
BrowserMatch "^the beast$" !is_good_request
...
SetEnvIf GEOIP_COUNTRY_CODE CN !is_good_request
...
SetEnvIf GEOIP_ISP "OHV Hosting" !is_good_request
...
<Location />
Require env is_good_request
</Location>
instead. So no matter how you try to write it as a workaround, it's going to
have some warts.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #1 from Philip Prindeville <ph...@redfish-solutions.com> ---
See also bug 53069.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #3 from Philip Prindeville <ph...@redfish-solutions.com> ---
(In reply to Christophe JAILLET from comment #2)
> So, this done on purpose.
Okay, so it's a feature and not a bug. ;-)
It's still counter-intuitive and more than a little confusing.
Security should be made simple-stupid, because after you've been hacked is not
the time to finally understand what your rules _really_ meant.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #6 from Jacob Champion <jc...@apache.org> ---
(In reply to Philip Prindeville from comment #5)
> (In reply to Jacob Champion from comment #4)
>
> > <idle thoughts>
> > Does part of the confusion stem from the fact that we are <RequireAny> by
> > default instead of <RequireAll>? Switching that alone might make some things
> > more intuitive.
> > </idle thoughts>
>
> Except that when one things of traditional mandatory access controls like
> ACLs and such, you execute the rules until you get your first conclusive
> match... which is what <RequireAny> does.
While that might be true -- and I'm not convinced that's an accurate
description of all MAC systems -- we're not using an ACL (or a MAC)
authorization system here. It's a very flexible (perhaps too flexible),
multi-paradigm system, and I would argue that you're just as likely to see
role-based authz with some of the more advanced authorization modules.
Perhaps the best thing to agree on is that any behavior might be "astonishing"
to some, and we should try to do what is least astonishing to the widest
possible range of users.
Anyway: there's a good chance that this is neither here nor there. Maybe all we
need to do is review what directives are considered neutral/success/failure in
the authz system.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #5 from Philip Prindeville <ph...@redfish-solutions.com> ---
(In reply to Jacob Champion from comment #4)
> <idle thoughts>
> Does part of the confusion stem from the fact that we are <RequireAny> by
> default instead of <RequireAll>? Switching that alone might make some things
> more intuitive.
> </idle thoughts>
Except that when one things of traditional mandatory access controls like ACLs
and such, you execute the rules until you get your first conclusive match...
which is what <RequireAny> does.
So changing over to <RequireAll> would be changing one violation of The
Principle of Least Astonishment for another... more of a lateral move than a
forward one.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #2 from Christophe JAILLET <ch...@wanadoo.fr> ---
When dealing with negative condition, corresponding code has the following
comment:
/* For negated directives, if the original result was denied
* then the new result is neutral since we can not grant
* access simply because authorization was not rejected.
*/
(see
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/aaa/mod_authz_core.c?revision=1756038&view=markup&sortby=date#l792)
So, this done on purpose.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #4 from Jacob Champion <jc...@apache.org> ---
Yeah, this is a case where the design seems conceptually sound but the end user
experience is not.
I am agreed that we should not, from an architectural perspective, allow access
to a resource if there are no modules positively indicating that authorization
is granted. But from a user perspective, I'd argue that many people intend for
Require not env disallowed
to *be* a positive declaration: "Allow anyone who isn't explicitly disallowed."
We should let users express this in a way that doesn't require five lines of
boolean logic.
(Well, I suppose we do, but it's not nearly as easy to parse:
Require expr "-z %{reqenv:disallowed}"
It's not intuitive that this check, which is effectively checking for the
absence of something, is considered positive authorization, but `Require not`
isn't.)
<idle thoughts>
Does part of the confusion stem from the fact that we are <RequireAny> by
default instead of <RequireAll>? Switching that alone might make some things
more intuitive.
</idle thoughts>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
--- Comment #7 from Philip Prindeville <ph...@redfish-solutions.com> ---
(In reply to Jacob Champion from comment #6)
> While that might be true -- and I'm not convinced that's an accurate
> description of all MAC systems -- we're not using an ACL (or a MAC)
> authorization system here. It's a very flexible (perhaps too flexible),
> multi-paradigm system, and I would argue that you're just as likely to see
> role-based authz with some of the more advanced authorization modules.
Yes, sorry. I was thinking specifically of the case where you're controlling
your decision based on IP address, host port, or some derivation of that (like
GeoIP).
> Perhaps the best thing to agree on is that any behavior might be
> "astonishing" to some, and we should try to do what is least astonishing to
> the widest possible range of users.
I can subscribe to that.
> Anyway: there's a good chance that this is neither here nor there. Maybe all
> we need to do is review what directives are considered
> neutral/success/failure in the authz system.
Someone explain to me again what the point of "neutral" is?
I've always thought that success == !failure and vice versa.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 60946] "Require not env" generates error
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60946
Philip Prindeville <ph...@redfish-solutions.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |champion.p@gmail.com,
| |humbedooh@apache.org,
| |philipp@redfish-solutions.c
| |om, wrowe@apache.org
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org