Re: Unix Permissions: Using groups to isolate users from webserver

[lists <lists () innocence-lost net>]

you can compile php as a cgi or as a shared object linked into apache,
however suexec becomes pretty pointless if you dont make php a cgi. There
are some snafu's with suexec, but once you get the permissions issues down
(files/directories that are/contain cgi's must be owned by the user they
are to run as and not be writeable to world/group, etc), it works pretty
well.

Perhaps what you should consider for your situation is something a little
more estoeric, perhaps something like extended posix acl's, rsbac
(rsbac.org), or even grsec's acl's, it has a bit of a learning curve
however once you get it deployed and working, you will be happy that you
did.


--

There are only two choices in life. You either conform the truth to your desire,
or you conform your desire to the truth. Which choice are you making?
On Wed, 1 Dec 2004, drax wrote:

> Date: Wed, 01 Dec 2004 03:17:14 +0100
> From: drax <drax () sweon net>
> To: Alexander Klimov <alserkli () inbox ru>
> Cc: security-basics () securityfocus com
> Subject: Re: Unix Permissions: Using groups to isolate users from webserver
>
> Hi,
>
> Thank you for you reply Alexander.
>
> Alexander Klimov wrote:
> > On Mon, 29 Nov 2004, drax wrote:
> >
> > > I am running a server, which has user accounts accessible through ssh
> > > and is
> > > running a few services, moreover, apache for serving http. Some of
> > > these users
> > > have vhosts, and therefor apache goes in various user's home dir to
> > > fetch the
> > > webpages. I need the users to have full control of their vhost'ed
> > > files, and
> > > that is why they are in their respective $HOME and belong to them.
> >
> > Note that it does not matter where the file resides -- to be
> > readable/writable
> > the only thing matters is its access mode.
>
> True, but the access modes of the directory containing it, also play a role.
> In my case, although most directory and files are readable, a couple
> directories up in the tree, there's an access mode blocking (no execution)
> anyone but the apache user from going in any deeper.
> This is to stop people from viewing the webserver files. So I can't store the
> user's vhost'ed files there (even with proper access modes) because the user
> wouldn't be able to see them.
>
> > > Some of their web pages (php scripts,etc) need to be able to write to
> > > the
> > > filesystem. Therefor apache must be able to write in those particular
> > > parts of
> > > their $HOME. Additionally, some of their web scripts (conf files with
> > > SQL
> > > passwords, etc), need to be protected from other users. But obvisouly,
> > > still
> > > be accessible by apache.
> > >
> > > The way I solved this problem is the following:
> > > [...]
> > > Do you believe my setup is correct and up to the task, or could it be
> > > circumvented in a matter of minutes?
> >
> >
> > Since your webserver is always executed with the same UID which allows to
> > read/write all users' data then every user who can execute something on
> > it has
> > exactly the same abilities.
> What do you mean by " the same UID which allows to read/write all users'
> data". That's if I execute the server as root right? But apache changes to the
> user/group you feed it in the conf files, and therefor gets (only) that user's
> rights. So unless the user specifically makes a file readable for that apache
> user, the webserver won't see the file.
> Correct me if I am wrong though.
>
> On the other hand, you made me realise something else which proves my
> solutions is worthless.
> Since the scripts (php, cgis) apache executes inherit the rights of the user
> apache is running as. And since any user can (with my solution) feed scripts
> to apache then any user can do whatever apache can do ie: fiddle around with
> other user's files (who have been setup for apache to read/write) and worst
> even, fiddle around with the main server files (main sites being hosted)
>
> > The proper way to solve your problem is to execute scripts with UIDs of
> > respected users:
> > http://httpd.apache.org/docs/suexec.html
> >
> > Note, that since usually php executed inside httpd you need to switch to
> > CGI
> > mode or use different UIDs for httpds for different vhosts (AFAIK this is
> > greatly simplified by Apache 2).
>
> I didn't quite catch what you meant by "switch to CGI mode". As for running a
> apache process per user, doesn't that get cumbersom if you start having alot
> of users?
> The suexec seems to be what I wanted in the first place but everywhere (conf
> files, docs, even you :p), it mentions CGI. That's what stopped me because I
> mainly have php scripts, not CGIs. Maybe it works anyway, I'll look into it.
>
> I'll keep you posted, thanks for the help.
>
> drax