NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Checking permissions is silly (Score:1)
How does that help? If an attacker has permission to change the contents of a config file then they may well have permission to chmod it back to 644 afterwards, surely?
Further, checking the permissions with stat() and then reading the file introduces a race condition, and so does reading it first and then statting.
Some programs like OpenSSH or Apache do check the permissions of private key files, .htpasswd files and so on. But this is because they contain sensitive information that should not be publicly *readable*. In any case message is more of a convenience to the user than a rigorous security measure: again, the permissions of the file can change between stat() and open(). And once a file has been publicly readable even for a moment, you should assume its contents are no longer secret (so just running chmod will quieten the message, but not fix the problem).
Now there are many security holes associated with /tmp and assuming nobody else can write to it. These are mostly symlink attacks based on predictable filenames and can be avoided by using File::Temp rather than handrolled code.
-- Ed Avis ed@membled.com
Reply to This
Re: (Score:1)
> How does that help? If an attacker has permission to change the contents of a config file then they may well have permission to chmod it back to 644 afterwards, surely?
No, they can't.
(Unless the attacker has root in which case the security of your program is irrelevant anyway)
adam@svn:~$ sudo vi tmp.pl
adam@svn:~$ sudo chmod 666 tmp.pl
adam@svn:~$ vi tmp.pl
adam@svn:~$ chmod 644 tmp.pl
chmod: changing permissions of `tmp.pl': Operation not permitted
> Further, checking the permissions with stat() and the
Re: (Score:1)
Well, quite. To change files in /etc you need to be root, and if you are root then you can make it appear that the files have not been altered. There are conceivable cases where by some freak event a config file was set up as o+w but the directory was not writable, but I have a hard time believing it's the application's job to check for that, any more than I think applications should be constantl
-- Ed Avis ed@membled.com
Re: (Score:1)
> So why is that case any more worth checking for?
We don't always only read files that were created at the time a program was installed?
Plugins appear afterwards, config files get backed up and restored. Who's to say the program hasn't been upgraded since you last ran?
There's a range of cases where this problem could appear from and not all of them would be a problem during the race window. But I agree some might, so it probably does makes sense to check both initially and then on the opened file handle.
Re: (Score:1)
You can open a file, and then stat the file handle...
Re: (Score:1)
Doesn't help. The permissions can be changed after you stat and while you still have the file open.
-- Ed Avis ed@membled.com
Re: (Score:1)
A tighter permission check, reasonably cheap: fstat, read, fstat again and check nothing but access time has changed.