Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner. The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
What is the difference between permissions of 600 and 700 for a directory, that is owned by root (group root)? Is there a reason why some directory should be set to 600 instead of 700?
Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner. The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
What is the difference between permissions of 600 and 700 for a directory, that is owned by root (group root)? Is there a reason why some directory should be set to 600 instead of 700?
600 is read and write for the owner whereas 700 is read write and execute. If there is nothing in the folder that needs to be executed than 600 would be correct.
On 07/20/10 4:54 PM, Larry Brower wrote:
Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner. The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
What is the difference between permissions of 600 and 700 for a directory, that is owned by root (group root)? Is there a reason why some directory should be set to 600 instead of 700?
600 is read and write for the owner whereas 700 is read write and execute. If there is nothing in the folder that needs to be executed than 600 would be correct.
um... on a directory, the X bit means you can LS the contents of the directory. of course, root ignores this anyways and overrides it.
At Tue, 20 Jul 2010 16:57:11 -0700 CentOS mailing list centos@centos.org wrote:
On 07/20/10 4:54 PM, Larry Brower wrote:
Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner. The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
What is the difference between permissions of 600 and 700 for a directory, that is owned by root (group root)? Is there a reason why some directory should be set to 600 instead of 700?
600 is read and write for the owner whereas 700 is read write and execute. If there is nothing in the folder that needs to be executed than 600 would be correct.
um... on a directory, the X bit means you can LS the contents of the directory. of course, root ignores this anyways and overrides it.
Note that execute access is only needed on a directory if you want to list its contents (eg ls). If you know ahead of time the name of the file in the directory you seek to access, you don't need execute access on the directory. Not having execute access on a directory keeps 'noisy' people from discovering the contents of the directory. This is a not unreasonably security setting.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Heller wrote:
At Tue, 20 Jul 2010 16:57:11 -0700 CentOS mailing list centos@centos.org wrote:
On 07/20/10 4:54 PM, Larry Brower wrote:
Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner. The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
What is the difference between permissions of 600 and 700 for a directory, that is owned by root (group root)? Is there a reason why some directory should be set to 600 instead of 700?
600 is read and write for the owner whereas 700 is read write and execute. If there is nothing in the folder that needs to be executed than 600 would be correct.
um... on a directory, the X bit means you can LS the contents of the directory. of course, root ignores this anyways and overrides it.
Note that execute access is only needed on a directory if you want to list its contents (eg ls). If you know ahead of time the name of the file in the directory you seek to access, you don't need execute access on the directory. Not having execute access on a directory keeps 'noisy' people from discovering the contents of the directory. This is a not unreasonably security setting.
This is what I meant to imply, however was not clear when I responded.
On 07/20/2010 05:17 PM, Robert Heller wrote:
um... on a directory, the X bit means you can LS the contents of the directory. of course, root ignores this anyways and overrides it.
Note that execute access is only needed on a directory if you want to list its contents (eg ls). If you know ahead of time the name of the file in the directory you seek to access, you don't need execute access on the directory.
You and John are both incorrect. Read access is sufficient to get a list of files and directories in a given directory. The execute bit on a directory is required to access the directory's contents. If a directory is 'rw-' for a user (other than root), the user can get a list of its contents using 'ls'. However, since the contents are not available, the user cannot stat() the names to determine what type of file they are, their size, their owner/group, etc. The user will also not be able to chdir to a sub-directory without execute access.
The fact that Doug has a directory with octal mode 0600 is probably an oversight which goes unnoticed because the root user gets the privilege of lax security checks.
----- Original Message ----
From: Robert Heller heller@deepsoft.com To: CentOS mailing list centos@centos.org Cc: CentOS mailing list centos@centos.org Sent: Tue, July 20, 2010 9:17:28 PM Subject: Re: [CentOS] directory permissions set to 600?
um... on a directory, the X bit means you can LS the contents of the directory. of course, root ignores this anyways and overrides it.
Note that execute access is only needed on a directory if you want to list its contents (eg ls). If you know ahead of time the name of the file in the directory you seek to access, you don't need execute access on the directory. Not having execute access on a directory keeps 'noisy' people from discovering the contents of the directory. This is a not unreasonably security setting.
Nope. for dirs, 'w' means "you can create and delete files" (because creating and deleting files means inserting and removing entries in the dir), "r" means "you can list the dir" (which makes sense, since what 'ls' does is reading the dir entries. 'x' means "you can cd into the directory)
Fer
On Tue, Jul 20, 2010 at 05:45:36PM -0600, Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner.
Heheheheh. That machine is so broken. Even 0700 would be unbelievably broken
The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
Sounds like some messed up wanna-be security person who doesn't grok Unix.
Basically nothing non-root running will work properly on these machines. And if everything is designed to run as root then the architect has shown other issues. "root" is the user of last recourse on a properly managed server.
On Tue, Jul 20, 2010 at 07:36:17PM -0700, Gordon Messmer wrote:
You and John are both incorrect. Read access is sufficient to get a list of files and directories in a given directory. The execute bit on a directory is required to access the directory's contents. If a directory is 'rw-' for a user (other than root), the user can get a list of its contents using 'ls'. However, since the contents are not available, the user cannot stat() the names to determine what type of file they are, their size, their owner/group, etc. The user will also not be able to chdir to a sub-directory without execute access.
IOW, ls will work fine, but ls -l will not. (To be specific, a plain old /bin/ls will work fine. If you have any ls options that need to read the contents of the directory, like -l or -F, it'll b0rk.)
On Tue, Jul 20, 2010 at 11:20:57PM -0400, Stephen Harris wrote:
Basically nothing non-root running will work properly on these machines. And if everything is designed to run as root then the architect has shown other issues. "root" is the user of last recourse on a properly managed server.
If it's an embedded server, like a home wifi router device, running everything as root isn't such a big deal. If it's a real server it's in deep trouble.
--keith
On Tue, Jul 20, 2010 at 08:30:48PM -0700, Keith Keller wrote:
On Tue, Jul 20, 2010 at 11:20:57PM -0400, Stephen Harris wrote:
Basically nothing non-root running will work properly on these machines. And if everything is designed to run as root then the architect has shown other issues. "root" is the user of last recourse on a properly managed server.
If it's an embedded server, like a home wifi router device, running everything as root isn't such a big deal. If it's a real server it's in deep trouble.
/me glances at the Centos mailing list header...
OK :-)
On 07/20/2010 08:30 PM, Keith Keller wrote:
IOW, ls will work fine, but ls -l will not. (To be specific, a plain old /bin/ls will work fine. If you have any ls options that need to read the contents of the directory, like -l or -F, it'll b0rk.)
Well, to be *specific*, reading the contents of the directory is allowed. That's what 'ls' will do. The attributes of the files contained within the directory are not read from the directory. They're returned by stat() on the paths composed of the directory path plus the names returned by reading the directory. The stat() call will fail, since you can read the directory's own content, but cannot access any of the items within the directory.
If it's an embedded server, like a home wifi router device, running everything as root isn't such a big deal. If it's a real server it's in deep trouble.
They're the configuration files for a firewall package. It's fine that they're readable only by root. No other user would have any use for them, as only the root user can manipulate iptables entries.
Thank you to everyone for the replies. The system(s) in question is a CentOS 5.5 server(s) (both development and production). The directory in question, in this case, is a firewall program (and monitor) to assist us with ip tables. I am also asking the developers of this product, as to why the directory is 600 and not 700.
(see below for more response)
On Tue, Jul 20, 2010 at 11:42 PM, Gordon Messmer yinyang@eburg.com wrote:
On 07/20/2010 08:30 PM, Keith Keller wrote:
IOW, ls will work fine, but ls -l will not. (To be specific, a plain old /bin/ls will work fine. If you have any ls options that need to read the contents of the directory, like -l or -F, it'll b0rk.)
Well, to be *specific*, reading the contents of the directory is allowed. That's what 'ls' will do. The attributes of the files contained within the directory are not read from the directory. They're returned by stat() on the paths composed of the directory path plus the names returned by reading the directory. The stat() call will fail, since you can read the directory's own content, but cannot access any of the items within the directory.
I did some more testing, and if the directory is owned by root, and the permissions are either 0600 or 0700 only root can cd into it or even do an ls (or ls -l) on it and see the contents.
If the directory is owned by a non-privileged user, and the directory is 0600, then that user can do an ls on the directory (ls dir/) and see the files. When that same user does an ls -l on the directory (ls -l dir/), it will show the files, but not attributes of the files. This same non-privileged user is not allowed to cd into the directory either. If the directory is 0700, then the non-privileged user that is the owner (and root) can cd into it, as well as do a ls -l to see the file attributes.
OK, my question from all of this is what is the difference between 0600 and 0700 for a directory that is owned by root? I see the difference for a directory owned by a non-privileged user, but if root is the owner, then only root can do anything with it, or see anything in it, and root will ignore the fact that the execute bit is not set for the owner. So what is the benefit of making a root owned directory 0600 instead of 0700?
On 07/21/2010 10:30 AM, Ski Dawg wrote:
OK, my question from all of this is what is the difference between 0600 and 0700 for a directory that is owned by root? I see the difference for a directory owned by a non-privileged user, but if root is the owner, then only root can do anything with it, or see anything in it, and root will ignore the fact that the execute bit is not set for the owner. So what is the benefit of making a root owned directory 0600 instead of 0700?
For a directory, no difference aside from a command like 'find' explicitly testing permission bits. The mode could just as well be 0000.
For an ordinary file, there would be a difference. For root to execute a file, at least one of the three execute permission bits must be set.
On 07/21/2010 08:30 AM, Ski Dawg wrote:
OK, my question from all of this is what is the difference between 0600 and 0700 for a directory that is owned by root?
For a directory, there's effectively no difference because the Linux kernel does lax security checking for the root user. Root will be allowed to read and write files, and access directory contents regardless of the permissions indicated on the filesystem.
On Wed, Jul 21, 2010 at 7:45 PM, Gordon Messmer yinyang@eburg.com wrote:
On 07/21/2010 08:30 AM, Ski Dawg wrote:
OK, my question from all of this is what is the difference between 0600 and 0700 for a directory that is owned by root?
For a directory, there's effectively no difference because the Linux kernel does lax security checking for the root user. Root will be allowed to read and write files, and access directory contents regardless of the permissions indicated on the filesystem.
Thank you for the responses to this. I was suspecting that there wasn't a difference for root owned directories, but I wanted to confirm, making sure I wasn't crazy.
On 07/20/2010 08:20 PM, Stephen Harris wrote:
On Tue, Jul 20, 2010 at 05:45:36PM -0600, Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner.
Heheheheh. That machine is so broken. Even 0700 would be unbelievably broken
Why?
Take a look in /etc, and I promise that you'll find entries that are 0600 and 0700. You might even notice that the permissions on /etc/shadow are unusually restricted. Do you believe the permissions on /etc/shadow are also broken?
The directory is for the firewall package for the server, so it is not something malicious. Checking some other systems, they also have this directory and the permissions on those servers is also 600, so it isn't just a messed up permissions on this one machine.
Sounds like some messed up wanna-be security person who doesn't grok Unix.
Perhaps I am more charitable. I'm inclined to believe that it's the result of a typo in the installation script that tends to go unnoticed because the root user isn't locked out by the error.
Basically nothing non-root running will work properly on these machines. And if everything is designed to run as root then the architect has shown other issues. "root" is the user of last recourse on a properly managed server.
There are some things (setting iptables entries for instance) that only the root user is allowed to do. While daemons should not run as root if they don't need to, these configuration files aren't for a daemon. Furthermore, as authentication can typically only be done by root, you'll find that there are quite a few very secure packages which still run as the root user. Take sshd for instance. It has a nice design that puts a lot of work in a process that doesn't run as root, but the parent process still does.
On Tue, Jul 20, 2010 at 10:51:15PM -0700, Gordon Messmer wrote:
On 07/20/2010 08:20 PM, Stephen Harris wrote:
On Tue, Jul 20, 2010 at 05:45:36PM -0600, Ski Dawg wrote:
Hello all,
Today, I ran across a directory in /etc/ on one of our servers whose permissions where set to 600 (drw-------) with root being the owner.
Heheheheh. That machine is so broken. Even 0700 would be unbelievably broken
Why?
Sorry, I mis-read. I had thought you'd written that /etc itself was 0600. That'd be so broken...
-
Fernando Gleiser -
Gordon Messmer -
John R Pierce -
Keith Keller -
Larry Brower -
Robert Heller -
Robert Nichols -
Ski Dawg -
Stephen Harris