Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This came up in a comment to another question and I'd love it if someone could explain the reasons for this to me.

I suggested having Apache log the errors for a given VHost to a user's home directory. This was shot down because it was insecure. Why?

I asked for clarification in a reply comment but all I got was that it's insecure to have root writing in a folder not owned by root. Again, could someone explain?

Thanks,

Bart.

share|improve this question
4  
What's Apache doing running as root - the principle of least privilege cries out against that! –  Jonathan Leffler Sep 29 '09 at 14:31
1  
Apache is running as www, but is being started as root so it can bind to port 80 as is the norm. Apparently it also logs as root. –  Bart B Sep 30 '09 at 16:16

2 Answers 2

up vote 31 down vote accepted

Because an evil user can maliciously try to point the file root is writing to a different location. This is not so simple, but really possible.

As an example, if a user would find the way to make a symlink from the supposed Apache log to, say, /etc/shadow you'll suddenly have an unusable system. Apache (root) would overwrite your users' credentials making the system faulty.

ln -s /etc/shadow /home/eviluser/access.log

If the access.log file is not writable by the user it can be difficult to hijack it, but avoiding the possibility is better!

A possibility could be to use logrotate to do the job, creating the link to a file not already existing, but that logrotate will overwrite as soon as the logs grows:

ln -s /etc/shadow /home/eviluser/access.log.1

Note:

The symlink method is only one of the possible attacks, given as a proof of concept.

Security has to be made with a White List mind, not blacklisting what we know to be an issue.

share|improve this answer
    
Is there a way to set permissions on it so they can only read the file and not delete, edit, or do anything else (like chown, chmod, etc.)? –  Joshua Sep 22 '09 at 15:46
    
you should do this operation on every possible target file! this writeable file is the liked one, not the link itself that is owned by the attacker as he created it. –  AlberT Sep 22 '09 at 15:54
2  
@Joshua: chown can only be performed by root. chmod can be performed by whoever owns the file. IIRC, renaming can be done by whoever owns the directory. As AlberT mentions, creating a link before root creates the file can be done by whoever can write to the directory. –  atk Sep 22 '09 at 15:54
2  
@atk: In addition, whoever owns the directory can generally remove files from it (unless the sticky +t bit is set), even if they have no write permission to the files themselves (because unlink() is a write to the directory, not the file). Even if root creates the file ahead of time, the directory owner could still be able to delete it and replace it with a symlink to something else. –  James Sneeringer Sep 24 '09 at 8:00
1  
If eviluser can write in /home/eviluser (or can change the permissions on the directory - they own it, IOW), then it doesn't matter what the permissions on access.log are; the eviluser can (re)move the file and place their symlink in its place. Another question is whether the software pays attention to what it opens. –  Jonathan Leffler Sep 29 '09 at 14:33

The general principle of not having processes write into a directory they don't own or trust is a good one. But in this particular case, it's reasonable to trust that the Apache code opens the log with O_NOFOLLOW etc: logging into a user's home directory is a common setup.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.