Re: Re: Security problem (ownership)

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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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 gwolfmosca[15]~$ mkdir -p /tmp/1/1/1/1/1
0 gwolfmosca[16]~$ chmod 000 /tmp/1/1/1
0 gwolfmosca[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 - gwolfgwolf.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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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 gwolfmosca[15]~$ mkdir -p /tmp/1/1/1/1/1
> 0 gwolfmosca[16]~$ chmod 000 /tmp/1/1/1
> 0 gwolfmosca[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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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 gwolfmosca[15]~$ mkdir -p /tmp/1/1/1/1/1
> 0 gwolfmosca[16]~$ chmod 000 /tmp/1/1/1
> 0 gwolfmosca[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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

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 gwolfmosca[15]~$ mkdir -p /tmp/1/1/1/1/1
> > 0 gwolfmosca[16]~$ chmod 000 /tmp/1/1/1
> > 0 gwolfmosca[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 - gwolfgwolf.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
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee