# Why are files like /etc/passwd readable by all?

## southsider

Pretty simple really, this seems to be a total arse to get around when you want to lock down user accounts - unless I'm missing something obvious...

What's the future? ACL's? SELinux?

:clueless:

Thanks

----------

## adaptr

How so ?

Can you explain to me how you would circumvent the authentication mechanism solely by being able to read the passwd file ?

There are several good howto's and guides on www.tldp.org on basic Linux security and authentication - search for "shadow passwords".

That was a free hint, by the way  :Wink: 

----------

## southsider

Thing is, I don't want users to be able to discover everything about my system configuration.

chroot jails seem a bit of a cop-out, though.

----------

## thatguyiam

There's jailshell if you really want to tie your users down.

----------

## sven-tek

they are free to see, because security by obscurity doesn't work   :Smile: 

for example, windows trys to hide information like this, but you can read 

one admin-password that has been changed the last time, from the cache if you are logged in as an administrator too. so windows is only safe because not the hole world knows it.

ups, did i tell?

----------

## southsider

I don't want users to be able to find out about other local users, though...

It's a simple pre-emptive measure.

----------

## nevynxxx

 *sven-tek wrote:*   

> they are free to see, because security by obscurity doesn't work   

 

One word....Cryptography.

The art of obscuring information. How does a shadow password file work....it MD5 hashes your password, i.e obscures it.

Show me one security system that *does not* use cryptography, and hence obscurity. I bet you can't.

Saying that, to get proper security you have to obscure the information in the most secure manner possible/reasonable.

To answer the OP, it doesn't matter if the users can read passwd, they cannot write to it, and they cannot read shadow. They cannot gain any useful information, except in the case they want to hack each other, and they have weak passwords.

----------

## southsider

My idea of a secure system is denying access to everything and then explicitly allowing access to things users require access to.

Apache seems to work that way.

----------

## spb

If you really want to deny access to stuff like this, SELinux can help. However, getting it working on the desktop (ie with X) is a non-trivial undertaking right now. And yes, the default behaviour is to deny everything that isn't explicitly allowed.

```
maya ~ # cat /etc/shadow 

cat: /etc/shadow: Permission denied
```

----------

## angoraspruce

 *nevynxxx wrote:*   

>  *sven-tek wrote:*   they are free to see, because security by obscurity doesn't work    
> 
> One word....Cryptography.
> 
> 

 

Encryption does not equal obscurity.  But rather than playing the dictionary game, I'll let looking the words up as an exercise for the reader!  :Wink: 

----------

## justanothergentoofanatic

Well, encryption is provably perfect obscurity. Even if you know everything about how the information was encrypted, you still can't decrypt the information. This is different from most forms of information hiding, where you can retrieve the information as long as you have a rough idea of how it was hidden.

However, nevy does have a valid point if you consider the complete human system instead of just the computers. Even if an e-mail was encrypted, you can always get the information from the person who wrote it. One could argue that encryption is useless obscurity since many hackers/crackers have successfully used social engineering to circumvent it.

Anyway, I think /etc/passwd is visible mainly for legacy reasons. Originally, programs needed to access /etc/passwd so they could validate accounts and verify passwords. But now that we have PAM to do authentication for us, I don't see the need for a world-readable /etc/passwd.

-Mike

----------

## RedDawn

 *spb wrote:*   

> If you really want to deny access to stuff like this, SELinux can help. However, getting it working on the desktop (ie with X) is a non-trivial undertaking right now. And yes, the default behaviour is to deny everything that isn't explicitly allowed.
> 
> ```
> maya ~ # cat /etc/shadow 
> 
> ...

 

I can agree with you on that one, i once tried to install SeLinux on gentoo but failed miserably.

Do you have X and other applications installed and running properly?   How about for web hosting with a control panel such as plesk, or cpanel.  do you think that the security the box applies into the system wont allow the control panels to work?

Thanks, and im sorry for hijacking this thread.  im done now.

----------

## j-m

 *southsider wrote:*   

> I don't want users to be able to find out about other local users, though...
> 
> It's a simple pre-emptive measure.

 

Did you ever try /bin/who...  :Question:   :Razz: 

----------

## teknomage1

Couldn't a user get a list of other local users by executing 'ls ../' from their home directory?

----------

## nevynxxx

My point was that the phrase "security through obscurity is worthless" is compleatly wrong. 

At a basic level, the only security that can be obtained, whilst still giving access to some services, is through obscurity.

Obviously some levels of obscurity (i.e cryptography) are better than others.

What is port knocking?? Is it obscurity or is it cryptography? It does after all have a key.

That key is easily sniffed though, at which point it becomes pure obscurity.

Port knocking is useful against script kiddies, i.e. they wont find any open ports. But very bad against a concerted hack attempt, as it gives a false sense of security.

@angoraspruce

[quote=http://www.askoxford.com/]

encrypt

/enkript/ 

   verb convert into code.

obscure

   adjective (obscurer, obscurest) 1 not discovered or known about; uncertain. 2 not well known. 3 not clearly expressed or easily understood. 4 hard to make out; indistinct. 

   verb conceal or make unclear.

[/quote]

That doesn't help much  :Smile: 

I would say cryptography was a subset of obscurity, where cryptography has known (or unknown) algorithms and known keys.[/quote]

----------

## rex123

The phrase "security though obscurity" normally refers to a security system that relies on other people not knowing how it works. eg hiding something in your shoe. This type of security can be very successful, but it is a mistake to rely on it. "Real" security is gained when you can tell the world exactly what your method is, and they still can't get at your data. That's where cryptography comes in. We all know (basically) how SSL works, for example, but it would take us a long time to decipher any SSL data we capture. Or that's the idea.

On a different subject...

 *Quote:*   

> My idea of a secure system is denying access to everything and then explicitly allowing access to things users require access to.
> 
> Apache seems to work that way

 

It seems to, but that's only because people generally use a default distributed configuration. With no deny rules, apache actually does the opposite - allows access to everything.

From http://httpd.apache.org/docs/mod/core.html#directory

 *Quote:*   

> 
> 
> Note that the default Apache access for <Directory /> is Allow from All. This means that Apache will serve any file mapped from an URL. It is recommended that you change this with a block such as
> 
>  <Directory />
> ...

 

----------

## nevynxxx

 *rex123 wrote:*   

> The phrase "security though obscurity" normally refers to a security system that relies on other people not knowing how it works. eg hiding something in your shoe. This type of security can be very successful, but it is a mistake to rely on it. "Real" security is gained when you can tell the world exactly what your method is, and they still can't get at your data. That's where cryptography comes in. We all know (basically) how SSL works, for example, but it would take us a long time to decipher any SSL data we capture. Or that's the idea.
> 
> 

 

Usually, start looking into port knocking though amd you get a whole lot of "security through obscurity doesn't work". This even though knowledge of the method is usless unless you know the exact algorithm, i.e. the key.

On the flip side a whole lot of military cryptography has used systems that would be obscurity by your definition. Enigma is the best example.

Unbreakable until someone got hold of an enigma machine.

I think I've made my point and gone wildly enough off topic now, so I'll stop arguing...

----------

## F.Ultra

 *Quote:*   

> Unbreakable until someone got hold of an enigma machine.

 Actually no, it was broken way before the cryptographers could get their hands on a enigma machine. But then again this is an extremely bad example of obscurity since the enigma does use a key. Security though obscurity is bad period.

----------

## nevynxxx

 *F.Ultra wrote:*   

> Actually no, it was broken way before the cryptographers could get their hands on a enigma machine. But then again this is an extremely bad example of obscurity since the enigma does use a key. Security though obscurity is bad period.

 

Ok, my bad, should really check things like that.....I do stand by the general jist though.

----------

## adaptr

By your reasoning, you claim to feel more secure if your home had an unlocked door that nobody could find, than if it had a normal door with a secure lock.

Think about it - I know which one I'd prefer.

There is a difference, but it's subtle enough that nobody's mentioned it yet.

----------

## southsider

OK if I could please knock this thread back on topic...

# chmod 751 /home

Any issues with this? I don't see any. All directories are still properly secured.

Will SELinux deal with stuff like normal users being able to lsmod and do other things they really should have no interest in?

----------

## spb

 *RedDawn wrote:*   

> I can agree with you on that one, i once tried to install SeLinux on gentoo but failed miserably.
> 
> Do you have X and other applications installed and running properly?   How about for web hosting with a control panel such as plesk, or cpanel.  do you think that the security the box applies into the system wont allow the control panels to work?

 Well, I have my desktop working perfectly under SELinux. Only things that don't work are dbus (because I haven't installed the policy for it yet), bittorrent (because I haven't written the policy yet), and mpd (ditto). Generally speaking you'll have problems with software that wants to do weird stuff yet isn't common enough for someone to have written a decent policy for it (normally meaning anything that isn't in Fedora 3).

----------

## nevynxxx

 *adaptr wrote:*   

> By your reasoning, you claim to feel more secure if your home had an unlocked door that nobody could find, than if it had a normal door with a secure lock.
> 
> Think about it - I know which one I'd prefer.
> 
> There is a difference, but it's subtle enough that nobody's mentioned it yet.

 

Who is that a reply to? It's a little difficult to make out.

----------

## adaptr

To you - which seems obvious to me  :Wink: 

Your position on obscurity vs. encryption, and encryption being a form of obscurity.

Perhaps the analogy falls a little short, but in general I do not think of encryption, decent encryption where you can tell a malicious 3rd party exactly which cipher you used, and he will still not be able to crack one message in exponential time, as anything like obscuring sensitive data.

Except in the very, very literal sense, of course...

Heh.

I'll rectify that: the analogy sux0rs  :Wink: 

----------

## southsider

So, any problems with 751'ing /home?

----------

## F.Ultra

I am actually running my /home/* as 700 to completely prohibit the users from even listing the other users homedirectories, and has yet to see any problems other than that the users of course cannot share files easily.

----------

## angoraspruce

 *southsider wrote:*   

> So, any problems with 751'ing /home?

 

To help you get your thread back on topic, "Go for it."  What's the worse that can happen?  If you find it a bit restrictive, you change it to something else.

On my system '/home' is 755, but my particular home directory, '/home/me', is 711.  No problems.

Best regards  :Smile: 

----------

## j-m

 *F.Ultra wrote:*   

> I am actually running my /home/* as 700 to completely prohibit the users from even listing the other users homedirectories, and has yet to see any problems other than that the users of course cannot share files easily.

 

Hmm, 0700 actually does not work for FTP because you need at least execute for the FTP daemon to work...

----------

## spb

 *F.Ultra wrote:*   

> I am actually running my /home/* as 700 to completely prohibit the users from even listing the other users homedirectories, and has yet to see any problems other than that the users of course cannot share files easily.

 Well, how about this then....

```
stephen:staff_r@maya ~ $ ls -ld /home

drwxr-xr-x  11 root root 4096 Feb 10 16:31 /home

stephen:staff_r@maya ~ $ ls -l /home

ls: /home/share: Permission denied

ls: /home/ftp: Permission denied

ls: /home/ciaranm: Permission denied

ls: /home/andrew: Permission denied

ls: /home/mwr: Permission denied

total 28

drwx------   2 root    root  16384 Oct 23 19:59 lost+found

drwxr-xr-x  96 stephen users  4096 Feb 17 02:18 stephen
```

----------

## nevynxxx

 *adaptr wrote:*   

> To you - which seems obvious to me 
> 
> Your position on obscurity vs. encryption, and encryption being a form of obscurity.
> 
> Perhaps the analogy falls a little short, but in general I do not think of encryption, decent encryption where you can tell a malicious 3rd party exactly which cipher you used, and he will still not be able to crack one message in exponential time, as anything like obscuring sensitive data.
> ...

 

Ohhhh no, no, no, no , no.....

My position is, encryption first, then obscurity *if it will help*.

I.e. use ssh, use public key authentication only, then impliment port knocking.

Or in this case, shadow password file already uses quite strong encryption, there doesn't seem to be much need to stop people seeing the passwd file.

lol...but I was talking in the very very literal sense, I was only bashing the phrase, not trying to say encryption is unnecessary with obscurity.

----------

## F.Ultra

spb: *lol* look at that  :Very Happy: 

----------

## southsider

One problem with 751 on /home:

In programs that require you navigate to your home directory through / you can't expand home, so you can't get into /home/alex or whatever.

Is there no way to allow listings on a directory, but only list files you should have read access to? Sounds a bit hacky, but I'm sure you know what I mean (and equally sure you can't, but worth a shot anyway).

----------

## spb

 *southsider wrote:*   

> Is there no way to allow listings on a directory, but only list files you should have read access to? Sounds a bit hacky, but I'm sure you know what I mean (and equally sure you can't, but worth a shot anyway).

 Yes, and it involves SELinux-- see my post above.  :Smile:  Other than that, and possibly other MAC systems, no.

----------

## adaptr

 *southsider wrote:*   

> Is there no way to allow listings on a directory, but only list files you should have read access to?

 

Not with traditional UNIX filesystems, no.

The point is that the browse permissions for a directories' contents are set on the directory itself - not on the individual files in it.

So you cannot separate them out.

----------

## southsider

spb:

You can still see the directories you're denied access to in your example.

I was hoping for a solution which lets you list /home and shows you the directories you're allowed access to, but doesn't distinguish between "permission denied" and "no such file or directory". So say I have two users, bob and fred.

as root:

# ls /home

bob

fred

# cd /home/asdf

-bash: cd: /home/asdf: No such file or directory

as bob

$ ls /home

bob

$ cd /home/asdf

-bash: cd: /home/asdf: Permission denied

$ cd /home/fred

-bash: cd: /home/fred: Permission denied

and vice versa for fred with bob.

----------

## adaptr

SELinux or any other MAC solution - as discussed earlier.

----------

## spb

 *southsider wrote:*   

> 
> 
> as bob
> 
> $ ls /home
> ...

 Doable, but not with any system out of the box AFAIK. It'd involve patching the kernel's directory access and stat functions, as well as finding some way to label the directories in question to turn on this behaviour.

----------

## nevynxxx

 *southsider wrote:*   

> $ ls /home
> 
> bob
> 
> $ cd /home/asdf
> ...

 

Shouldn't that be, "no such file or directory"?

Permission denied implies that this thing exists but your not allowed to use it.

----------

## southsider

That's exactly what I want. I don't want users to be able to probe for directories they're not supposed to see.

Thus there should be no difference between a non-existing directory and an existing directory where access is disallowed.

----------

## spb

 *southsider wrote:*   

> That's exactly what I want. I don't want users to be able to probe for directories they're not supposed to see.
> 
> Thus there should be no difference between a non-existing directory and an existing directory where access is disallowed.

 Patch the stat functions to return ENOENT instead of EACCES when a directory isn't readable. Then patch the routines responsible for listing directory contents.

----------

## zeek

 *southsider wrote:*   

> That's exactly what I want. I don't want users to be able to probe for directories they're not supposed to see.
> 
> Thus there should be no difference between a non-existing directory and an existing directory where access is disallowed.

 

My advice, don't use a *nix based system.  Neither SysV or *BSD style provides the kind of obsecurity that you desire.

----------

## southsider

It's not "obsecurity", it's Data Protection.

Why the hell should any of my users be able to find out the usernames of other users on a local system?

Can you ring up your bank and ask for the names of other people who bank with them?

----------

## teknomage1

Actually, not only can you find out other patron's names but you can ask yes or no questions regarding their balance.

----------

## angoraspruce

 *teknomage1 wrote:*   

> Actually, not only can you find out other patron's names but you can ask yes or no questions regarding their balance.

 

Hm....  I wonder if any of these partons are a certain Nazi by the name of Hitler?</godwin>  :Wink: 

----------

## teknomage1

Quirk's Exception: 

 Intentional invocation of Godwin's Law is ineffectual.

----------

## j-m

You are trying to do foolish stuff that will break basic system functionality. Don´t give your users SSH access if you cannot live with the fact that they can discover the highly secret reality - that they are not alone on your system.  :Rolling Eyes: 

----------

## southsider

I'm not giving users ssh access.

----------

## southsider

 *teknomage1 wrote:*   

> Actually, not only can you find out other patron's names but you can ask yes or no questions regarding their balance.

 

Are you serious? Which bank is that?

----------

## j-m

 *southsider wrote:*   

> I'm not giving users ssh access.

 

OK, so what is your problem?!  :Rolling Eyes: 

----------

## teknomage1

In reference to the bank balance thing, you just have to identify yourself to the bank as a creditor, meaning someone owes you money. For the list of patrons it's a bit more compoicated but having an account at a bank in the US is considered public information, whereas the exact balance is private unless you owe someone money. Anyway despite my reply about Quirk's exception, I do support angoraspruce's motion to end the thread.

----------

