Re: "Forbid" directive in core?
> On 27 Apr 2020, at 16:37, Eric Covener wrote: > > > Bumping a very old thread. tl;dr people are often surprised that when > Location sections have access control directives and overlap with the > filesystem it undoes the default > >Require all denied > We always warn against mixing with filesystem. That's just one of many gotchas that may arise from it. I wonder if a better solution would be to be much stricter about the division? Ideally make it a config error (switchable to a warning so as not to break too many old configs) to overlap them? A first-pass implementation might be for the Location directive to issue a warning if it matches a directory in the filesystem. -- Nick Kew
Re: "Forbid" directive in core?
On Mon, Apr 27, 2020 at 12:14 PM Yann Ylavic wrote: > > On Mon, Apr 27, 2020 at 5:37 PM Eric Covener wrote: > > > > Bumping a very old thread. tl;dr people are often surprised that when > > Location sections have access control directives and overlap with the > > filesystem it undoes the default > > > > Require all denied > > > > Thanks for pointing at this, I was wondering what baptx was talking > about on users@. TIL... > > What about upper sf proposal to default AuthMerging to "and"? > Would that be too disruptive? Or at least, if this is a direction, > could we do that in our default httpd.conf (and docs)? AuthMerging in default conf for at least the .ht* case seems to make sense. Haven't tested, never occurred to me before. Maybe because it was not analagous for 2.2 back then. I don't think we can change the compiled-in default in 2.4. Maybe in trunk?
Re: "Forbid" directive in core?
On Mon, Apr 27, 2020 at 5:37 PM Eric Covener wrote: > > Bumping a very old thread. tl;dr people are often surprised that when > Location sections have access control directives and overlap with the > filesystem it undoes the default > > Require all denied > Thanks for pointing at this, I was wondering what baptx was talking about on users@. TIL... What about upper sf proposal to default AuthMerging to "and"? Would that be too disruptive? Or at least, if this is a direction, could we do that in our default httpd.conf (and docs)?
Re: "Forbid" directive in core?
On Mon, Apr 27, 2020 at 11:37 AM Eric Covener wrote: > On Sat, Sep 28, 2013 at 12:21 PM Tim Bannister > wrote: > > The second time in a few days, I'm going to suggest adding an optional > parameter to a directive. > > > > Taking a leaf out of cascading stylesheets, how about “Forbidden On > Level=Important” and perhaps “Forbidden On Level=Indelible”? > > > > (the idea being that the “Indelible” level can't be removed). > > > > > > This lets distributions ship a fairly safe default configuration but > gives users enough scope to hang themselves. With this, “forbidden OFF” > isn't so risky and “Forbidden Off Level=Important” can carry a health > warning (and perhaps an ErrorLog warning as well). > > > > > > Too complex or worth having? What do people think? If there's appetite > for it then I will have a go at providing a patch. > > What do currently active people think of the original basic "Forbid" > or the one with tags/levels? > Most CSS experts will tell you that "!important" is bad and if you are using it, you didn't design your site properly. As someone who does a lot of config support, I also think this is overly complicated. - Y
Re: "Forbid" directive in core?
On Sat, Sep 28, 2013 at 12:21 PM Tim Bannister wrote: > > On 28 Sep 2013, at 14:19, Eric Covener wrote: > > > I've come back to this because I've struggled in another area with > > access_checker vs. access_checker_ex. I really think we need basic access > > control outside of Require and Satisfy. > > > > I have a copy of the "Forbidden" directive in mod_authz_core and I am > > currrently allowing ON/OFF flags. > > > > * using a new directive means someone won't casually add "forbidden OFF" > > when they think they're turnong on more access control with Require > > * we can document that "forbidden OFF" is extreme from the start. > > > > I am on the fence about having an argument at all. My fear is that it will > > evolve into a misguided FAQ of 'try forbidden OFF if you get a 403' then > > we're right back to > > > > > > Forbidden > > > > > > ... > > > > > > ... > > Require ldap-group cn=foo > > Forbidden OFF > > > > The second time in a few days, I'm going to suggest adding an optional > parameter to a directive. > > Taking a leaf out of cascading stylesheets, how about “Forbidden On > Level=Important” and perhaps “Forbidden On Level=Indelible”? > > (the idea being that the “Indelible” level can't be removed). > > > This lets distributions ship a fairly safe default configuration but gives > users enough scope to hang themselves. With this, “forbidden OFF” isn't so > risky and “Forbidden Off Level=Important” can carry a health warning (and > perhaps an ErrorLog warning as well). > > > Too complex or worth having? What do people think? If there's appetite for it > then I will have a go at providing a patch. Bumping a very old thread. tl;dr people are often surprised that when Location sections have access control directives and overlap with the filesystem it undoes the default Require all denied What do currently active people think of the original basic "Forbid" or the one with tags/levels?
Re: Forbid directive in core?
Am Samstag, 28. September 2013, 09:19:28 schrieb Eric Covener:
I've come back to this because I've struggled in another area with
access_checker vs. access_checker_ex. I really think we need basic
access control outside of Require and Satisfy.
I have a copy of the Forbidden directive in mod_authz_core and I
am currrently allowing ON/OFF flags.
* using a new directive means someone won't casually add forbidden
OFF when they think they're turnong on more access control with
Require
* we can document that forbidden OFF is extreme from the start.
I am on the fence about having an argument at all. My fear is that
it will evolve into a misguided FAQ of 'try forbidden OFF if you
get a 403' then we're right back to
Files .ht*
Forbidden
/Files
...
Location /
...
Require ldap-group cn=foo
Forbidden OFF
/location
Any thoughts on keeping the flag?
I am not sure this is enough. I think it can happen that one wants to
override one specific Forbidden but not any others. Consider the
following config:
Directory /
Forbidden
/Directory
Directory /srv/www
Forbidden off
/Directory
Files .ht*
Forbidden
/Files
If ! %{HTTP_METHOD} -in { GET, POST, HEAD }
Forbidden
/If
If I now want to allow PUT/DELETE for a specific directory without
allowing access to .htaccess files, that would be very difficult.
One idea similar but not quite like Tim's suggestion would be to add a
tag parameter to Forbidden, and to require the exact same tag
parameter for a forbidden off to be effective.
Directory /
Forbidden tag=paths
/Directory
Directory /srv/www
Forbidden tag=paths off
/Directory
Files .ht*
Forbidden tag=htaccess
/Files
If ! %{HTTP_METHOD} -in { GET, POST, HEAD }
Forbidden tag=methods
/If
Then a
If ! %{HTTP_METHOD} -in { GET, POST, HEAD }
Forbidden tag=methods off
/If
would do the right thing.
If we don't offer a wildcard 'Forbidden tag=* off', then the
possiblity for misguided FAQs to cause security issues would be
limited. Not specifying a tag would imply tag=default and not tag=*.
Of course, instead of doing this for a new Forbidden tag, we could do
this for all authz, too.
Files .ht*
AuthTag htaccess
Require all denied
/AuthTag
/Files
Authz directives would then only be merged within their own tag.
Maybe requiring to define the possible tags before use would be a good
idea to catch typos. And allowing to define which of these may be used
in .htaccess would be good, too. Probably some other name than 'tag'
would be better. Scope? Tier?
I haven't though about how easy this would be to implement in a
performant way, though. And it would increase the complexity of the
configurations quite a bit. But it would make it easier to avoid
accidental security problems.
Re: Forbid directive in core?
I've come back to this because I've struggled in another area with access_checker vs. access_checker_ex. I really think we need basic access control outside of Require and Satisfy. I have a copy of the Forbidden directive in mod_authz_core and I am currrently allowing ON/OFF flags. * using a new directive means someone won't casually add forbidden OFF when they think they're turnong on more access control with Require * we can document that forbidden OFF is extreme from the start. I am on the fence about having an argument at all. My fear is that it will evolve into a misguided FAQ of 'try forbidden OFF if you get a 403' then we're right back to Files .ht* Forbidden /Files ... Location / ... Require ldap-group cn=foo Forbidden OFF /location Any thoughts on keeping the flag? On Mon, Jun 10, 2013 at 5:17 PM, Stefan Fritsch s...@sfritsch.de wrote: On Monday 10 June 2013, Plüm, Rüdiger, Vodafone Group wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. I thought someone might object to the duplication w/ AAA or the presence in the core, so opting for RTC. Why indeed in core? Indeed, why in core? Maybe mod_authz_core would be more appropriate? And what is bad about require all denied? That it is too easy to override by accident. Actually, mod_allowhandlers in trunk allows SetHandler forbidden which more or less does what Forbid does (unless one overrides the Handler later on). But that's even more confusing than a separate Forbid. I am in favor of adding something that denies and is difficult to override by accident. But maybe the combination Require all denied AuthMerging and inherit would do the trick, denoting that later sections are merged with and unless AuthMerging is set explicitly. But I guess it could still happen that this would be overriden by accident by an AuthMerging or later on. Another possibility would be AuthMerging immutable stating that sections merged later would be ignored. But I can't think of any sane usage except with require all denied. So maybe the Forbid is enough? -- Eric Covener cove...@gmail.com
Re: Forbid directive in core?
On 28 Sep 2013, at 14:19, Eric Covener cove...@gmail.com wrote: I've come back to this because I've struggled in another area with access_checker vs. access_checker_ex. I really think we need basic access control outside of Require and Satisfy. I have a copy of the Forbidden directive in mod_authz_core and I am currrently allowing ON/OFF flags. * using a new directive means someone won't casually add forbidden OFF when they think they're turnong on more access control with Require * we can document that forbidden OFF is extreme from the start. I am on the fence about having an argument at all. My fear is that it will evolve into a misguided FAQ of 'try forbidden OFF if you get a 403' then we're right back to Files .ht* Forbidden /Files ... Location / ... Require ldap-group cn=foo Forbidden OFF /location The second time in a few days, I'm going to suggest adding an optional parameter to a directive. Taking a leaf out of cascading stylesheets, how about “Forbidden On Level=Important” and perhaps “Forbidden On Level=Indelible”? (the idea being that the “Indelible” level can't be removed). This lets distributions ship a fairly safe default configuration but gives users enough scope to hang themselves. With this, “forbidden OFF” isn't so risky and “Forbidden Off Level=Important” can carry a health warning (and perhaps an ErrorLog warning as well). Too complex or worth having? What do people think? If there's appetite for it then I will have a go at providing a patch. -- Tim Bannister – is...@jellybaby.net
Re: Forbid directive in core?
Am 28.09.2013 18:21, schrieb Tim Bannister: On 28 Sep 2013, at 14:19, Eric Covener cove...@gmail.com wrote: I've come back to this because I've struggled in another area with access_checker vs. access_checker_ex. I really think we need basic access control outside of Require and Satisfy. I have a copy of the Forbidden directive in mod_authz_core and I am currrently allowing ON/OFF flags. * using a new directive means someone won't casually add forbidden OFF when they think they're turnong on more access control with Require * we can document that forbidden OFF is extreme from the start. I am on the fence about having an argument at all. My fear is that it will evolve into a misguided FAQ of 'try forbidden OFF if you get a 403' then we're right back to Files .ht* Forbidden /Files ... Location / ... Require ldap-group cn=foo Forbidden OFF /location The second time in a few days, I'm going to suggest adding an optional parameter to a directive. Taking a leaf out of cascading stylesheets, how about “Forbidden On Level=Important” and perhaps “Forbidden On Level=Indelible”? (the idea being that the “Indelible” level can't be removed). This lets distributions ship a fairly safe default configuration but gives users enough scope to hang themselves. With this, “forbidden OFF” isn't so risky and “Forbidden Off Level=Important” can carry a health warning (and perhaps an ErrorLog warning as well). Too complex or worth having? too complex and dangerous nobody is able to say what is effective in wathever directory in case of a lot of .conf-files including vhost-snippets which *all* may contain Directory-directives now you can say the last one wins and if needed name files with prefixes with your proposal in production environments nobody knows what is state of play because you have distribution-snippets from httpd package *and* web-app-packages too and they may contain any variant even if you say 100 times they most not ship it that way it does not help the enduser which configure settings never get active while thining he overrides no - i want and need to be sure that if i create a z-my-overrides.conf and include it at the end of httpd.conf it does what i expect signature.asc Description: OpenPGP digital signature
Re: Forbid directive in core?
On 10 Jun 2013, at 14:35, Eric Covener cove...@gmail.com wrote:
I'd like to add an immutable Forbid directive to the core and use it in some
places in the default configuration instead of require all denied.
http://people.apache.org/~covener/forbid.diff
This protects from a broad Location or If being added that supercedes
Directory/Files.
I thought someone might object to the duplication w/ AAA or the presence in
the core, so opting for RTC.
Just a comment: other places that do broadly similar things often have a “deny
by default” philosophy. I like this approach.
Obviously this isn't going to please admins with existing configurations, so is
there a way to design the mechanism so it's still possible to get something
more strict than we have at the moment?
In terms of directives, this could look like:
Directory /
# For example, insiset that exemptions must be defined in the same place as
the Forbid is set.
Forbid
ForbidExemption /srv/web /nfs/foo/bar
/Directory
# Require HTTPS except from IPv4 localhost
If %{REQUEST_SCHEME} != HTTPS (! -R 127.0.0.0/8 )
# Expression evaluation doesn't need exemptions
Forbid
/Directory
--
Tim Bannister – is...@jellybaby.net
Re: Forbid directive in core?
On 10 Jun 2013, at 14:35, Eric Covener wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. I thought someone might object to the duplication w/ AAA or the presence in the core, so opting for RTC. Why indeed in core? The interaction of different scopes - not least Location vs filesystem paths - is a source of regular confusion. I'm not sure adding another directive with different, one-off semantics helps. Does it really override Location/If in all circumstances? Could it create (new) gotchas with Alias, internal Rewrites, or similar mapping functions? Also the comment Irrevocably forbids access to the enclosing scope could easily be read as going up a level in a hierarchy (it confused me momentarily, and I had the context of the complete patch to figure out what you meant by saying enclosing rather than current or just this). -- Nick Kew
RE: Forbid directive in core?
-Original Message- From: Nick Kew [mailto:n...@webthing.com] Sent: Montag, 10. Juni 2013 16:02 To: dev@httpd.apache.org Subject: Re: Forbid directive in core? On 10 Jun 2013, at 14:35, Eric Covener wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. I thought someone might object to the duplication w/ AAA or the presence in the core, so opting for RTC. Why indeed in core? Indeed, why in core? And what is bad about require all denied? Regards Rüdiger
Re: Forbid directive in core?
On 10 Jun 2013, at 3:35 PM, Eric Covener cove...@gmail.com wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. Does Location supercede Directory/Files? My understanding is that if the Directory/Files says no, then the access is denied, regardless of what Location says. Or to state it another way, we are successful until the first directive comes along that says denied. We don't deny, and then later on change our mind and succeed again. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Forbid directive in core?
On 10 Jun 2013, at 15:17, Graham Leggett minf...@sharp.fm wrote: On 10 Jun 2013, at 3:35 PM, Eric Covener cove...@gmail.com wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. Does Location supercede Directory/Files? My understanding is that if the Directory/Files says no, then the access is denied, regardless of what Location says. Or to state it another way, we are successful until the first directive comes along that says denied. We don't deny, and then later on change our mind and succeed again. I think that “dangerous” behaviour IS how httpd behaves. Have a look at the end of http://httpd.apache.org/docs/2.4/sections.html#merging -- Tim Bannister – is...@jellybaby.net
Re: Forbid directive in core?
Why indeed in core? Started there because that's where AccessFileName lives.
Re: Forbid directive in core?
On Monday 10 June 2013, Tim Bannister wrote: On 10 Jun 2013, at 15:17, Graham Leggett minf...@sharp.fm wrote: On 10 Jun 2013, at 3:35 PM, Eric Covener cove...@gmail.com wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. Does Location supercede Directory/Files? My understanding is that if the Directory/Files says no, then the access is denied, regardless of what Location says. Or to state it another way, we are successful until the first directive comes along that says denied. We don't deny, and then later on change our mind and succeed again. I think that “dangerous” behaviour IS how httpd behaves. Have a look at the end of http://httpd.apache.org/docs/2.4/sections.html#merging I think the real problem is that AuthzMerging defaults to off. Having a default of and would have been a lot safer, but that cannot be changed in 2.4 anymore. And there is not even a way to make AuthzMerging default to and globally. Time for a DefaultAuthzMerging XXX or an AuthzMerging XXX inherit directive?
Re: Forbid directive in core?
On Monday 10 June 2013, Plüm, Rüdiger, Vodafone Group wrote: I'd like to add an immutable Forbid directive to the core and use it in some places in the default configuration instead of require all denied. http://people.apache.org/~covener/forbid.diff This protects from a broad Location or If being added that supercedes Directory/Files. I thought someone might object to the duplication w/ AAA or the presence in the core, so opting for RTC. Why indeed in core? Indeed, why in core? Maybe mod_authz_core would be more appropriate? And what is bad about require all denied? That it is too easy to override by accident. Actually, mod_allowhandlers in trunk allows SetHandler forbidden which more or less does what Forbid does (unless one overrides the Handler later on). But that's even more confusing than a separate Forbid. I am in favor of adding something that denies and is difficult to override by accident. But maybe the combination Require all denied AuthMerging and inherit would do the trick, denoting that later sections are merged with and unless AuthMerging is set explicitly. But I guess it could still happen that this would be overriden by accident by an AuthMerging or later on. Another possibility would be AuthMerging immutable stating that sections merged later would be ignored. But I can't think of any sane usage except with require all denied. So maybe the Forbid is enough?
