Mailing List Archive

"Forbid" directive in core?
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.
Re: "Forbid" directive in core? [ In reply to ]
On 10 Jun 2013, at 14:35, Eric Covener <covener@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 – isoma@jellybaby.net
Re: "Forbid" directive in core? [ In reply to ]
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? [ In reply to ]
> -----Original Message-----
> From: Nick Kew [mailto:nick@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? [ In reply to ]
On 10 Jun 2013, at 3:35 PM, Eric Covener <covener@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
--
Re: "Forbid" directive in core? [ In reply to ]
On 10 Jun 2013, at 15:17, Graham Leggett <minfrin@sharp.fm> wrote:
> On 10 Jun 2013, at 3:35 PM, Eric Covener <covener@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 – isoma@jellybaby.net
Re: "Forbid" directive in core? [ In reply to ]
> Why indeed in core?

Started there because that's where AccessFileName lives.
Re: "Forbid" directive in core? [ In reply to ]
On Monday 10 June 2013, Tim Bannister wrote:
> On 10 Jun 2013, at 15:17, Graham Leggett <minfrin@sharp.fm> wrote:
> > On 10 Jun 2013, at 3:35 PM, Eric Covener <covener@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? [ In reply to ]
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?
Re: "Forbid" directive in core? [ In reply to ]
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 <sf@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
covener@gmail.com
Re: "Forbid" directive in core? [ In reply to ]
On 28 Sep 2013, at 14:19, Eric Covener <covener@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 – isoma@jellybaby.net
Re: "Forbid" directive in core? [ In reply to ]
Am 28.09.2013 18:21, schrieb Tim Bannister:
> On 28 Sep 2013, at 14:19, Eric Covener <covener@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 zzzzz-my-overrides.conf
and include it at the end of httpd.conf it does what i expect
Re: "Forbid" directive in core? [ In reply to ]
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? [ In reply to ]
On Sat, Sep 28, 2013 at 12:21 PM Tim Bannister <isoma@jellybaby.net> wrote:
>
> On 28 Sep 2013, at 14:19, Eric Covener <covener@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.

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
<Files ".ht*">
Require all denied
</Files>

What do currently active people think of the original basic "Forbid"
or the one with tags/levels?
Re: "Forbid" directive in core? [ In reply to ]
On Mon, Apr 27, 2020 at 11:37 AM Eric Covener <covener@gmail.com> wrote:

> On Sat, Sep 28, 2013 at 12:21 PM Tim Bannister <isoma@jellybaby.net>
> 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? [ In reply to ]
On Mon, Apr 27, 2020 at 5:37 PM Eric Covener <covener@gmail.com> 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
> <Files ".ht*">
> Require all denied
> </Files>

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? [ In reply to ]
On Mon, Apr 27, 2020 at 12:14 PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Mon, Apr 27, 2020 at 5:37 PM Eric Covener <covener@gmail.com> 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
> > <Files ".ht*">
> > Require all denied
> > </Files>
>
> 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? [ In reply to ]
> On 27 Apr 2020, at 16:37, Eric Covener <covener@gmail.com> 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
> <Files ".ht*">
> Require all denied
> </Files>

We always warn against mixing <Location> 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