Jerry Stuckle wrote:
> Raffaele Morelli wrote:
> > Bob Proulx wrote:
> > > 2) The ownership of the files by root are safe. The default owner is
> > > root. Files owned by root with the default permissions are not
> > > writable by the web process. Files in the default configuration are
> > > not exploitable by that vulnerability which requires write access to
> > > files in the DocumentRoot. There is never a problem with web files
> > > owned by the root user.
>
> It also means only the root user can modify those files.
Yes. That is by intent and design. Users should not be modifying
system files! For example if you install squirrelmail it will include
/usr/share/squirrelmail/**.php files in the package. Root owns those
files. This is good because that prevents any other account from
being able to modify those files. That is just long standing good
design.
> It is a very bad idea to use the root user to do such mundane
> things.
System administration is hardly mundane. It is often misunderstood
(as in this thread) but very important work.
> It is much better to have the files owned by a non-privileged user
> (not www-data), and provide read access to the web user.
Files owned by squirrelmail are not user files. They belong to the
package. Root is the natural owner of those files.
> I see having to use root to modify user files as a major problem.
User files? Why bring those up? You keep talking about user files
but expanding that to cover all files. That is the point I am
objecting to. I thought you and I had converged in other thread but I
guess not. Sigh. Continued misunderstanding.
All of the world is not user files. I object to the statements above
that conclude that because any file is owned by root that all work
must be done as root. That is an incorrect deduction.
If you as a web developer are going to be uploading files to be used
in a web site then the most natural thing would be for your non-root
(and non-www-data) account to own those files. (Why would root even
be considered for that purpose? Why would you think that root is
needed for this purpose? That is a real puzzler!)
Regardless from this it cannot be concluded that having a file owned
by root is a security vulnerability. It is not. The ownership of the
files by root are safe. If you still do not believe this then please
file a bug report so that it may be peer reviewed.
> > Quite wrong.
> > Unless you are administering your own server with just you as user
> > there's no problem in using root for everything.
> > But if you have other users you should grant write permissions to the
> > website document root for them to upload stuff and simply you can't let
> > anyone other than you to access as root (would you?).
> > Now, rwx permissions and unprivileged users exist for that, root
> > ownership is absolutely not needed.
>
> I see this as a huge problem, even on my own servers. It is way to
> easy to make a mistake that can destroy your system. Try rm -r .
> from the wrong directory, for instance. But then some people use
> root for everything.
Humorously you should try 'rm -r .' on a recent system. Sure, make it
safe first.
# mkdir /tmp/testdir
# cd /tmp/testdir
# rm -r .
rm: cannot remove directory: ‘.’
This is now required behavior by POSIX.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/rm.html
The rm utility is forbidden to remove the names dot and dot-dot in
order to avoid the consequences of inadvertently doing something like:
rm -r .*
Personally I think this is a "nanny state" type of behavior. It
annoys me. It shouldn't be prevented by the rm command. It is a
kernel system policy layer decision. It can be useful to allow the
_attempt_ to remove "." which must fail. In the past it was useful to
allow root to unlink ".." from a directory. But now rm is required to
avoid trying it.
> But then some people use root for everything.
And that is bad. Often because of lack of experience. Eventually
they will make a mistake and it will bite them and then they will be
more cautious.
Of course so far no one in this thread is proposing that all work be
done as root. Let's drop that please. (No! I haven't suggested all
work be done as root either.)
> > > > Someone should explain why it's safe using root as the
> > > > owner of php scripts instead of an unprivileged user
> > > > (with no write permission on dir/files).
> > >
> > > Actually either would be okay. As long as the non-priviledge user is
> > > NOT the www-data user. As long as file permissions prevent the
> > > www-data from being able to write to the DocumentRoot.
>
> As noted above, I do not agree it is OK.
I need your definition of "OK" in this context. Not OK means what?
I think it must mean personal preference. Because I see no security
vulnerability using a non-root non-www-data account for PHP files.
Files owned by a non-root and non-www-data account are safe because
the web process owned by www-data cannot write to those files. This
would be the normal typical case for user files. (Almost by
definition since the files would be owned by the user.) Users
typically own their own files. Uploading files to a web site isn't
system administration any more than writing personal diary entries or
editing a spreadsheet. None of those need root.
Files owned by root are safe because the web process owned by www-data
cannot write to those files. Note that this does not cause the
process to be run as root. It does not. The web process is still run
as the www-data user. Note that this does not require all work to be
done as root. It does not. It doesn't make sense to "do all of your
web hacking as root". Use your non-root non-www-data account for
uploading web files. Note that the presence of root owned files is
not a security vulnerability. Packaged files will be owned by root
for example and that is not a security vulnerability.
Files owned by www-data are not safe due to the reasoning previously
discussed. Not safe because the web process also running as www-data
can write those files and it removes the OS security layer. In PHP
traps and pitfalls such as insufficient quoting and other issues are
too common and mistakes like that allow the attacker to wedge in
additional files. That is the situation of the original poster's
report that started this thread. Because the files were changed to
www-data an exploit through the PHP code reportedly allowed the
attacker to turn a system into a spam source. That sounds very not
safe to me.
> BTW - your quoting style is not consistent, making it difficult to
> see which are your comments and which are in the post you are
> replying to.
Agreed. I had to manually and carefully correct the quoting on the
sections I responded to here.
Bob
Attachment:
signature.asc
Description: Digital signature