Mailing List Archive: Cherokee: users

Security problem (ownership)

Index | Next | Previous | View Threaded

skinkie at xs4all

Apr 16, 2008, 1:32 PM

Post #1 of 19 (1203 views)
Permalink

Security problem (ownership)

Hi,

I wonder if someone can reproduce this problem:

Make a file:

echo "Cherokee... don't be so naughty" > test.html
chmod 000 test.html

...access the file with cherokee; I expect this is not 'by design'.

Stefan

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

adefacc at tin

Apr 16, 2008, 2:23 PM

Post #2 of 19 (1181 views)
Permalink

Re: Security problem (ownership) [In reply to]

Stefan de Konink wrote:
>
> Hi,
>
> I wonder if someone can reproduce this problem:
>
> Make a file:
>
> echo "Cherokee... don't be so naughty" > test.html
> chmod 000 test.html
>
> ...access the file with cherokee; I expect this is not 'by design'.

If you are root, then you have no limits ...
and yes, this is by design ...

OK, if user is root, then readability has to be verified
explicitely before opening the file.

Indeed here some parametric policy could be added,
i.e. access only files readable by world, by group, by user.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

skinkie at xs4all

Apr 16, 2008, 2:34 PM

Post #3 of 19 (1189 views)
Permalink

Re: Security problem (ownership) [In reply to]

> Stefan de Konink wrote:
>>
>> Hi,
>>
>> I wonder if someone can reproduce this problem:
>>
>> Make a file:
>>
>> echo "Cherokee... don't be so naughty" > test.html
>> chmod 000 test.html
>>
>> ...access the file with cherokee; I expect this is not 'by design'.
>
> If you are root, then you have no limits ...
> and yes, this is by design ...

I have now updated the config with user 'nobody'. After clearing my cache
I get the 403.

> OK, if user is root, then readability has to be verified
> explicitely before opening the file.
>
> Indeed here some parametric policy could be added,
> i.e. access only files readable by world, by group, by user.

Yes, this is my opinion too.

Stefan

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

alvaro at sun

Apr 17, 2008, 1:16 AM

Post #4 of 19 (1171 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

On 17 Apr 2008, at 00:06, A.D.F. wrote:
> Stefan de Konink wrote:
>>
>> I wonder if someone can reproduce this problem:
>>
>> Make a file:
>>
>> echo "Cherokee... don't be so naughty" > test.html
>> chmod 000 test.html
>>
>> ...access the file with cherokee; I expect this is not 'by design'.
>
> If you are root, then you have no limits ...
> and yes, this is by design ...
>
> OK, if user is root, then readability has to be verified
> explicitely before opening the file.

In my understanding, file system access permission checks belongs to
the operating system. Running a program as root user implies a number
of things: it can open a low port, it can jail itself, it can change
system limits, AND it can read every file in the system. That is how
Unix systems work.

That's why Cherokee supports user changing, and all the modern
operating systems include a 'web server user' such as www-data, httpd
or www.

> Indeed here some parametric policy could be added,
> i.e. access only files readable by world, by group, by user.

I'm not sure of this at all. Running servers as root is highly
discouraged because of this kind of problems. By adding those rules we
would be duplicating a work that the underling operating system will
perform anyway, which means, the server would be slower and the only
thing that we would get is to slightly improve the behavior of the
server under a certain -let's call it- "misconfiguration"; or at
least: 'not recommended' configuration.

IMO the best thing we could do is to warn the user if the server runs
as root. Maybe cherokee-admin could pop a red, flashy warning message
if the server is configured to run as root. So, even if it is tougher
I would try to educate people rather than "fix" Cherokee for hiding
some of the potential problems of running a server as super-user.

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

alvaro at sun

Apr 17, 2008, 1:28 AM

Post #5 of 19 (1176 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

On 17 Apr 2008, at 10:16, Alvaro Lopez Ortega wrote:
> On 17 Apr 2008, at 00:06, A.D.F. wrote:
>> Stefan de Konink wrote:
>>>
>>> I wonder if someone can reproduce this problem:
>>>
>>> Make a file:
>>>
>>> echo "Cherokee... don't be so naughty" > test.html
>>> chmod 000 test.html
>>>
>>> ...access the file with cherokee; I expect this is not 'by design'.
>>
>> If you are root, then you have no limits ...
>> and yes, this is by design ...
>>
>> OK, if user is root, then readability has to be verified
>> explicitely before opening the file.
>
> In my understanding, file system access permission checks belongs to
> the operating system. Running a program as root user implies a
> number of things: it can open a low port, it can jail itself, it can
> change system limits, AND it can read every file in the system. That
> is how Unix systems work.
>
> That's why Cherokee supports user changing, and all the modern
> operating systems include a 'web server user' such as www-data,
> httpd or www.
>
>> Indeed here some parametric policy could be added,
>> i.e. access only files readable by world, by group, by user.
>
> I'm not sure of this at all. Running servers as root is highly
> discouraged because of this kind of problems. By adding those rules
> we would be duplicating a work that the underling operating system
> will perform anyway, which means, the server would be slower and the
> only thing that we would get is to slightly improve the behavior of
> the server under a certain -let's call it- "misconfiguration"; or at
> least: 'not recommended' configuration.
>
> IMO the best thing we could do is to warn the user if the server
> runs as root. Maybe cherokee-admin could pop a red, flashy warning
> message if the server is configured to run as root. So, even if it
> is tougher I would try to educate people rather than "fix" Cherokee
> for hiding some of the potential problems of running a server as
> super-user.

I was just thinking; it is more than that..

Do we want Cherokee to know about ACLs? Because permission checking is
trivial for user/group/others, but it gets messy when you have to deal
with Access Control Lists. Moreover, what's up with the new NFS4/ZFS
permissions? It's got 18 permissions instead to the old 3 read/write/
execute permissions. Besides, it supports negative ACEs and three
special entries for 'user owner', 'group owner' and 'everybody', plus
the ACL mask.

We do not want to play that game. The operating system is there for a
very good reason. :-)

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

alberto.caso at adaptia

Apr 17, 2008, 1:54 AM

Post #6 of 19 (1180 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

El jue, 17-04-2008 a las 10:28 +0200, Alvaro Lopez Ortega escribió:
> Do we want Cherokee to know about ACLs? Because permission checking is
> trivial for user/group/others, but it gets messy when you have to deal
> with Access Control Lists.

I think POSIX access() function handles all this, but anyway I agree
with you: Cherokee should not try to check permissions. Too much
overhead (in developer time and in runtime) for something with no gains.

Regards,

--
Alberto Caso Palomino
Adaptia - http://www.adaptia.es
alberto.caso[at]adaptia.es

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

adefacc at tin

Apr 17, 2008, 11:38 AM

Post #7 of 19 (1164 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

Alvaro Lopez Ortega wrote:
>
> On 17 Apr 2008, at 00:06, A.D.F. wrote:
> > Stefan de Konink wrote:
> >> . . .
> >
> > OK, if user is root, then readability has to be verified
> > explicitely before opening the file.
>
> In my understanding, file system access permission checks belongs to
> the operating system. Running a program as root user implies a number
> of things: it can open a low port, it can jail itself, it can change
> system limits, AND it can read every file in the system. That is how
> Unix systems work.
>
> That's why Cherokee supports user changing, and all the modern
> operating systems include a 'web server user' such as www-data, httpd
> or www.
>
> > Indeed here some parametric policy could be added,
> > i.e. access only files readable by world, by group, by user.
>
> I'm not sure of this at all. Running servers as root is highly
> discouraged because of this kind of problems. By adding those rules we
> would be duplicating a work that the underling operating system will
> perform anyway, which means, the server would be slower and the only
> thing that we would get is to slightly improve the behavior of the
> server under a certain -let's call it- "misconfiguration"; or at
> least: 'not recommended' configuration.
>
> IMO the best thing we could do is to warn the user if the server runs
> as root. Maybe cherokee-admin could pop a red, flashy warning message
> if the server is configured to run as root. So, even if it is tougher
> I would try to educate people rather than "fix" Cherokee for hiding
> some of the potential problems of running a server as super-user.

Yes, but even if you run a Web Server with a user not equal to root,
you may want to let the web server to serve only certain static files,
i.e. those that are:
- readable by others;
- readable by group.

Imagine to have two checkbox (per server or per virtual server)
for the above two possibilities.

If you check the first option,
then a static file has to be readable by others
in order to be served by Cherokee.

You only need to use:

chmod o+r file-name(s)
or
chmod o-r file-name(s)

to enable or disable access to selected files / directories.

This is very useful because it allows you to fine grade
the accessibility of files that can be sent to clients by Cherokee.

If none of the above filters are selected then
it is enough that at least one readable bit (user, group, others)
is on to let Cherokee to serve a file / directory.

Of course, in practice, there is no overhead in applying
such filters.

Greetings.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

adefacc at tin

Apr 17, 2008, 11:40 AM

Post #8 of 19 (1166 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

Alvaro Lopez Ortega wrote:
>
> On 17 Apr 2008, at 10:16, Alvaro Lopez Ortega wrote:
> > On 17 Apr 2008, at 00:06, A.D.F. wrote:
> >> Stefan de Konink wrote:
> >>>>
>
> I was just thinking; it is more than that..
>
> Do we want Cherokee to know about ACLs?

Absolutely not.

> We do not want to play that game. The operating system is there for a
> very good reason. :-)

Yes, I agree, but there is a third "unexpensive" way
(see my previous email).

Greetings.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

alvaro at sun

Apr 17, 2008, 11:55 AM

Post #9 of 19 (1169 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

On 17 Apr 2008, at 20:38, A.D.F. wrote:
> Alvaro Lopez Ortega wrote:
>> On 17 Apr 2008, at 00:06, A.D.F. wrote:
>>> Stefan de Konink wrote:
>>>> . . .
>>>
>>> OK, if user is root, then readability has to be verified
>>> explicitely before opening the file.
>>
>> In my understanding, file system access permission checks belongs to
>> the operating system. Running a program as root user implies a number
>> of things: it can open a low port, it can jail itself, it can change
>> system limits, AND it can read every file in the system. That is how
>> Unix systems work.
>>
>> That's why Cherokee supports user changing, and all the modern
>> operating systems include a 'web server user' such as www-data, httpd
>> or www.
>>
>>> Indeed here some parametric policy could be added,
>>> i.e. access only files readable by world, by group, by user.
>>
>> I'm not sure of this at all. Running servers as root is highly
>> discouraged because of this kind of problems. By adding those rules
>> we
>> would be duplicating a work that the underling operating system will
>> perform anyway, which means, the server would be slower and the only
>> thing that we would get is to slightly improve the behavior of the
>> server under a certain -let's call it- "misconfiguration"; or at
>> least: 'not recommended' configuration.
>>
>> IMO the best thing we could do is to warn the user if the server runs
>> as root. Maybe cherokee-admin could pop a red, flashy warning message
>> if the server is configured to run as root. So, even if it is tougher
>> I would try to educate people rather than "fix" Cherokee for hiding
>> some of the potential problems of running a server as super-user.
>
> Yes, but even if you run a Web Server with a user not equal to root,
> you may want to let the web server to serve only certain static files,
> i.e. those that are:
> - readable by others;
> - readable by group.
>
> Imagine to have two checkbox (per server or per virtual server)
> for the above two possibilities.
>
> If you check the first option,
> then a static file has to be readable by others
> in order to be served by Cherokee.
>
> You only need to use:
>
> chmod o+r file-name(s)
> or
> chmod o-r file-name(s)
>
> to enable or disable access to selected files / directories.
>
> This is very useful because it allows you to fine grade
> the accessibility of files that can be sent to clients by Cherokee.
>
> If none of the above filters are selected then
> it is enough that at least one readable bit (user, group, others)
> is on to let Cherokee to serve a file / directory.
>
> Of course, in practice, there is no overhead in applying
> such filters.

I may be missing something.. but, if you don't want to allow cherokee
to send a file, you would only have to change its permissions and the
web server wouldn't need to know about it.

In fact, the patch that you committed to 0.6 would only work on legacy
environments, and it would be source of problems if ACLs are used. For
example, a file permissions could be 000 but at the same time, it
could include an ACE allowing the web server user to read it anyway.

The usual solution is to call access() to check whether the program is
allowed to access the file, but in the case of Cherokee I do not think
it is worth using it because of the performance penalty. I would
rather keep it trying to read it and handling the failure in case it
could access the file.

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

adefacc at tin

Apr 17, 2008, 12:20 PM

Post #10 of 19 (1171 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

Alvaro Lopez Ortega wrote:
>
> On 17 Apr 2008, at 20:38, A.D.F. wrote:
> > Alvaro Lopez Ortega wrote:
> >> On 17 Apr 2008, at 00:06, A.D.F. wrote:
> >>> Stefan de Konink wrote:
> >>>> . . .
> >>>
> >>> OK, if user is root, then readability has to be verified
> >>> explicitely before opening the file.
> >>
> >> In my understanding, file system access permission checks belongs to
> >> the operating system. Running a program as root user implies a number
> >> of things: it can open a low port, it can jail itself, it can change
> >> system limits, AND it can read every file in the system. That is how
> >> Unix systems work.
> >>
> >> That's why Cherokee supports user changing, and all the modern
> >> operating systems include a 'web server user' such as www-data, httpd
> >> or www.
> >>
> >>> Indeed here some parametric policy could be added,
> >>> i.e. access only files readable by world, by group, by user.
> >>
> >> I'm not sure of this at all. Running servers as root is highly
> >> discouraged because of this kind of problems. By adding those rules
> >> we
> >> would be duplicating a work that the underling operating system will
> >> perform anyway, which means, the server would be slower and the only
> >> thing that we would get is to slightly improve the behavior of the
> >> server under a certain -let's call it- "misconfiguration"; or at
> >> least: 'not recommended' configuration.
> >>
> >> IMO the best thing we could do is to warn the user if the server runs
> >> as root. Maybe cherokee-admin could pop a red, flashy warning message
> >> if the server is configured to run as root. So, even if it is tougher
> >> I would try to educate people rather than "fix" Cherokee for hiding
> >> some of the potential problems of running a server as super-user.
> >
> > Yes, but even if you run a Web Server with a user not equal to root,
> > you may want to let the web server to serve only certain static files,
> > i.e. those that are:
> > - readable by others;
> > - readable by group.
> >
> > Imagine to have two checkbox (per server or per virtual server)
> > for the above two possibilities.
> >
> > If you check the first option,
> > then a static file has to be readable by others
> > in order to be served by Cherokee.
> >
> > You only need to use:
> >
> > chmod o+r file-name(s)
> > or
> > chmod o-r file-name(s)
> >
> > to enable or disable access to selected files / directories.
> >
> > This is very useful because it allows you to fine grade
> > the accessibility of files that can be sent to clients by Cherokee.
> >
> > If none of the above filters are selected then
> > it is enough that at least one readable bit (user, group, others)
> > is on to let Cherokee to serve a file / directory.
> >
> > Of course, in practice, there is no overhead in applying
> > such filters.
>
> I may be missing something.. but, if you don't want to allow cherokee
> to send a file, you would only have to change its permissions and the
> web server wouldn't need to know about it.
>
> In fact, the patch that you committed to 0.6 would only work on legacy
> environments, and it would be source of problems if ACLs are used. For
> example, a file permissions could be 000 but at the same time, it
> could include an ACE allowing the web server user to read it anyway.

OK, then a configuration option (compile time)
should suffice to enable/disable this feature in 0.6.2 and higher
(default: enabled, because this is what 95% of users want).

> The usual solution is to call access() to check whether the program is
> allowed to access the file, but in the case of Cherokee I do not think
> it is worth using it because of the performance penalty. I would
> rather keep it trying to read it and handling the failure in case it
> could access the file.

Yes, I know about what you are saying,
but lots of systems out there don't have filesystems with ACLs,
so I think that this simple feature could help at least 80% - 90%
of Cherokee users.

A warning about the unusefulness of this feature
with filesystems having ACLs and with sysadmins that tweak them,
would suffice; if you have and use ACLs, you don't want to use
this feature.

So, the final solution could be:

[ ] enable readability bit filters (only legacy systems, NO ACLs)
NOTE: if enabled, at least 1 readability bit (user,group,world)
has to be set in order to allow access to static files

[ ] filter to require "world bit" readability

[ ] filter to require "group bit" readability

I am not really advocating for including this feature into 0.7
but we could start to think about it.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

skinkie at xs4all

Apr 17, 2008, 12:22 PM

Post #11 of 19 (1164 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

On Thu, 17 Apr 2008, A.D.F. wrote:

> So, the final solution could be:
>
> [ ] enable readability bit filters (only legacy systems, NO ACLs)
> NOTE: if enabled, at least 1 readability bit (user,group,world)
> has to be set in order to allow access to static files
>
> [ ] filter to require "world bit" readability
>
> [ ] filter to require "group bit" readability

[ ] enable a message if Cherokee runs as root

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

alvaro at sun

Apr 17, 2008, 1:49 PM

Post #12 of 19 (1163 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

On 17 Apr 2008, at 21:22, Stefan de Konink wrote:
> On Thu, 17 Apr 2008, A.D.F. wrote:
>
>> So, the final solution could be:
>>
>> [ ] enable readability bit filters (only legacy systems, NO ACLs)
>> NOTE: if enabled, at least 1 readability bit (user,group,world)
>> has to be set in order to allow access to static files
>>
>> [ ] filter to require "world bit" readability
>>
>> [ ] filter to require "group bit" readability
>
> [ ] enable a message if Cherokee runs as root

I would go for:

- Warn user if cherokee runs as root:
This is the source of the problem, the user should know about this
and be aware of the misconfiguration.

- Let the OS do its job and take care of the permissions, and
therefore return errors only when the server cannot access the
resource. The idea is to be consistent with the system, if programs
run by root have super-powers, there is no reason to treat Cherokee
differently.

If we went the let's-try-to-make-root-safe way, we would have to fix a
bunch of additional issues. For instance, it wouldn't make sense to
chroot the server if it runs as root, but again, that is not a problem
that we ought to face.

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

Nikolai.Kondrashov at oktetlabs

Apr 17, 2008, 1:53 PM

Post #13 of 19 (1167 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

Alvaro Lopez Ortega wrote:
> I would go for:
>
> - Warn user if cherokee runs as root:
> This is the source of the problem, the user should know about this
> and be aware of the misconfiguration.
>
> - Let the OS do its job and take care of the permissions, and
> therefore return errors only when the server cannot access the
> resource. The idea is to be consistent with the system, if programs
> run by root have super-powers, there is no reason to treat Cherokee
> differently.
I'm not implying, that I have a say in this :), but I totally agree.

Sincerely,
Nick
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

gwolf at gwolf

Apr 18, 2008, 1:56 PM

Post #14 of 19 (1154 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

Alvaro Lopez Ortega dijo [Thu, Apr 17, 2008 at 08:55:12PM +0200]:
> The usual solution is to call access() to check whether the program is
> allowed to access the file, but in the case of Cherokee I do not think
> it is worth using it because of the performance penalty. I would
> rather keep it trying to read it and handling the failure in case it
> could access the file.

I fully agree on �lvaro here. Besides, there are several different
extended permission systems in (not-as-wide-as-Unix's-but-still) use,
and access() might not be able to give the full information -
i.e. while access() follows symlinks in Unix, it won't follow the
whatsitsname equivalents in Windows, as they are plain files.

In Unix, the user you run as should determine the
permissions. Remember that people can do strange and ingenious things
via FUSE (i.e. an example of a VERY bad interface design, but still a
convenient way to work under some circumstances is FlickrFS - Files
might just appear and disappear from under your feet with no prior
warning as tags/sets are created/deleted/modified). There are
filesystems based on SMB, even on SSH, which also carry some strangish
semantics... And Cherokee is not who should determine what is readable
and what is not.

--
Gunnar Wolf - gwolf[at]gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

gwolf at gwolf

Apr 18, 2008, 2:00 PM

Post #15 of 19 (1156 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

A.D.F. dijo [Fri, Apr 18, 2008 at 09:16:04PM +0000]:
> > If we went the let's-try-to-make-root-safe way, we would have to fix a
> > bunch of additional issues. For instance, it wouldn't make sense to
> > chroot the server if it runs as root, but again, that is not a problem
> > that we ought to face.
>
> I understand the reasoning,
> but indeed above proposal is not about fixing root security,
> but to introduce a new and inexpensive way to limit web access
> to normal user's files in systems that don't use ACLs.
>
> Think about a user that runs Cherokee but that don't want
> to give public access to a few files / directories
> placed below web root and that is not convenient
> to place somewhere else because the server is chrooted,
> it runs with an unpriviledge user, there are programs
> that use those specific paths, etc.

Umh, for a non-root user, if you have a chmod 000 directory in the
path, the system won't try to enter:

0 gwolf[at]mosca[15]~$ mkdir -p /tmp/1/1/1/1/1
0 gwolf[at]mosca[16]~$ chmod 000 /tmp/1/1/1
0 gwolf[at]mosca[17]~$ ls -l /tmp/1/1/1/1
ls: cannot access /tmp/1/1/1/1: Permission denied

So you'd be patching this only for the very corner case when you are
running as root _and_ are trying to hide something from root. Does it
make sense?

--
Gunnar Wolf - gwolf[at]gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

adefacc at tin

Apr 18, 2008, 2:16 PM

Post #16 of 19 (1159 views)
Permalink

Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

Alvaro Lopez Ortega wrote:
>
> On 17 Apr 2008, at 21:22, Stefan de Konink wrote:
> > On Thu, 17 Apr 2008, A.D.F. wrote:
> >
> >> So, the final solution could be:
> >>
> >> [ ] enable readability bit filters (only legacy systems, NO ACLs)
> >> NOTE: if enabled, at least 1 readability bit (user,group,world)
> >> has to be set in order to allow access to static files
> >>
> >> [ ] filter to require "world bit" readability
> >>
> >> [ ] filter to require "group bit" readability
> >
> > [ ] enable a message if Cherokee runs as root
>
> I would go for:
>
> - Warn user if cherokee runs as root:
> This is the source of the problem, the user should know about this
> and be aware of the misconfiguration.
>
> - Let the OS do its job and take care of the permissions, and
> therefore return errors only when the server cannot access the
> resource. The idea is to be consistent with the system, if programs
> run by root have super-powers, there is no reason to treat Cherokee
> differently.
>
> If we went the let's-try-to-make-root-safe way, we would have to fix a
> bunch of additional issues. For instance, it wouldn't make sense to
> chroot the server if it runs as root, but again, that is not a problem
> that we ought to face.

I understand the reasoning,
but indeed above proposal is not about fixing root security,
but to introduce a new and inexpensive way to limit web access
to normal user's files in systems that don't use ACLs.

Think about a user that runs Cherokee but that don't want
to give public access to a few files / directories
placed below web root and that is not convenient
to place somewhere else because the server is chrooted,
it runs with an unpriviledge user, there are programs
that use those specific paths, etc.

I know that this "may" look a bit weird, but having the possibility
to filter web accesses (static files) by that way, it would allow
95% of legacy users (maybe embedded systems too)
to easily solve their access problems;
the remaining 5% don't need this feature because
they use ACLs directly, so they can leave it disabled
(default setting), maybe there could even be
a ./configure --enable-readfile-access-filter option to compile
or not compile the feature.

Isn't this a cool idea for 0.8 ?

(There is no need to answer if it definetely is not ;-)

Greetings.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

alvaro at sun

Apr 18, 2008, 3:06 PM

Post #17 of 19 (1159 views)
Permalink

Re: [cherokee-dev] Re: [cherokee-dev] Re: Security problem (ownership) [In reply to]

On 18 Apr 2008, at 23:00, Gunnar Wolf wrote:
> A.D.F. dijo [Fri, Apr 18, 2008 at 09:16:04PM +0000]:
>>> If we went the let's-try-to-make-root-safe way, we would have to
>>> fix a
>>> bunch of additional issues. For instance, it wouldn't make sense to
>>> chroot the server if it runs as root, but again, that is not a
>>> problem
>>> that we ought to face.
>>
>> I understand the reasoning,
>> but indeed above proposal is not about fixing root security,
>> but to introduce a new and inexpensive way to limit web access
>> to normal user's files in systems that don't use ACLs.
>>
>> Think about a user that runs Cherokee but that don't want
>> to give public access to a few files / directories
>> placed below web root and that is not convenient
>> to place somewhere else because the server is chrooted,
>> it runs with an unpriviledge user, there are programs
>> that use those specific paths, etc.
>
> Umh, for a non-root user, if you have a chmod 000 directory in the
> path, the system won't try to enter:
>
> 0 gwolf[at]mosca[15]~$ mkdir -p /tmp/1/1/1/1/1
> 0 gwolf[at]mosca[16]~$ chmod 000 /tmp/1/1/1
> 0 gwolf[at]mosca[17]~$ ls -l /tmp/1/1/1/1
> ls: cannot access /tmp/1/1/1/1: Permission denied
>
> So you'd be patching this only for the very corner case when you are
> running as root _and_ are trying to hide something from root. Does it
> make sense?

Well, and the worst thing is that, even if we tried to make root
execution safe we would most likely fail.

That isn't a battle we ought to face, actually. Thinking of the system
architecture, the operating system is only the layer that should make
the decision on whether a file is accessible.

I do agree with ADF on trying to make users life easier by adding new
features (with no performance penalty), however I do not think that
checking the permission on the server would be a good thing because
all the architectural and technical reason we have commented previously.

IMO our best option is to add more global checks to ensure that the
user gets a big flashy warning whenever he tries to configure the
server in a non-recommended way (such as running it as root).

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

adefacc at tin

Apr 18, 2008, 4:03 PM

Post #18 of 19 (1160 views)
Permalink

Re: [cherokee-dev] Re: [cherokee-dev] Re: Security problem(ownership) [In reply to]

Gunnar Wolf wrote:
>
> A.D.F. dijo [Fri, Apr 18, 2008 at 09:16:04PM +0000]:
> > > If we went the let's-try-to-make-root-safe way, we would have to fix a
> > > bunch of additional issues. For instance, it wouldn't make sense to
> > > chroot the server if it runs as root, but again, that is not a problem
> > > that we ought to face.
> >
> > I understand the reasoning,
> > but indeed above proposal is not about fixing root security,
> > but to introduce a new and inexpensive way to limit web access
> > to normal user's files in systems that don't use ACLs.
> >
> > Think about a user that runs Cherokee but that don't want
> > to give public access to a few files / directories
> > placed below web root and that is not convenient
> > to place somewhere else because the server is chrooted,
> > it runs with an unpriviledge user, there are programs
> > that use those specific paths, etc.
>
> Umh, for a non-root user, if you have a chmod 000 directory in the
> path, the system won't try to enter:
>
> 0 gwolf[at]mosca[15]~$ mkdir -p /tmp/1/1/1/1/1
> 0 gwolf[at]mosca[16]~$ chmod 000 /tmp/1/1/1
> 0 gwolf[at]mosca[17]~$ ls -l /tmp/1/1/1/1
> ls: cannot access /tmp/1/1/1/1: Permission denied
>
> So you'd be patching this only for the very corner case when you are
> running as root _and_ are trying to hide something from root. Does it
> make sense?

The aim would be that your user would be able to read/write those files
but if they haven't the world bit on they would not be served
by Cherokee, i.e.:

-rw-rw--- 1 www httpd this-file-is-not-served.jpg

-rw-rw-r- 1 www httpd this-file-is-served.gif

drwxrwxr-- 2 www httpd this-directory-is-not-accessible

Directories could be accessed only if x access bit is set.

--
Nick Name: A.D.F.
E-Mail: <adefacc () tin ! it>
E-Mail-Format: Plain Text only (please); view using font Courier New
--
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

gwolf at gwolf

Apr 20, 2008, 2:51 PM

Post #19 of 19 (1117 views)
Permalink

Re: [cherokee-dev] Re: [cherokee-dev] Re: Security problem(ownership) [In reply to]

A.D.F. dijo [Fri, Apr 18, 2008 at 11:03:46PM +0000]:
> > Umh, for a non-root user, if you have a chmod 000 directory in the
> > path, the system won't try to enter:
> >
> > 0 gwolf[at]mosca[15]~$ mkdir -p /tmp/1/1/1/1/1
> > 0 gwolf[at]mosca[16]~$ chmod 000 /tmp/1/1/1
> > 0 gwolf[at]mosca[17]~$ ls -l /tmp/1/1/1/1
> > ls: cannot access /tmp/1/1/1/1: Permission denied
> >
> > So you'd be patching this only for the very corner case when you are
> > running as root _and_ are trying to hide something from root. Does it
> > make sense?
>
> The aim would be that your user would be able to read/write those files
> but if they haven't the world bit on they would not be served
> by Cherokee, i.e.:
>
> -rw-rw--- 1 www httpd this-file-is-not-served.jpg
> -rw-rw-r- 1 www httpd this-file-is-served.gif
> drwxrwxr-- 2 www httpd this-directory-is-not-accessible
>
> Directories could be accessed only if x access bit is set.

Urgh... sounds TOO patchy and ugly!

Base case: Site-wide Cherokee. Runs as www-user. That case is
completely covered, right?

Corner case: Cherokee installation where the user spawns his own
process. Here, your solution _would_ apply. Anyway, I'd strongly favor
not this solution (as it breaks many assumptions - i.e. I might want
to have umask 0700 on all of my files as a system-wide policy, and it
would single-handedly block me from sharing _anything_ via a
user-spawned Cherokee). In any case, I'd suggest a configuration file
setting specifying files to be denied. And yes, it already exists ;-)

> E-Mail-Format: Plain Text only (please); view using font Courier New

Ugh, sorry, I don't have that font installed in my xterm. I hope I
didn't misunderstand you ;-)

--
Gunnar Wolf - gwolf[at]gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com