LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   /etc/passwd does users 'man' and 'nobody' really need a login shell? (https://www.linuxquestions.org/questions/linux-security-4/etc-passwd-does-users-man-and-nobody-really-need-a-login-shell-706336/)

darin722 02-20-2009 09:39 PM

/etc/passwd does users 'man' and 'nobody' really need a login shell?
 
Hi I'm trying to write up some basic guidlines for securing a linux server. The scenario is that I've been asked to administer(and secure) a linux server running mysql. No users except me will log in directly, only a webserver will access the database. Previous administrators went away mad and may be interested in compromising the system.

I'm farily new to linux system administration and I'm not entirely sure of my approach. My thought is to audit the /etc/passwd file and disallow login ability to EVERYONE except my user account. In the default installation of ubuntu server I'm practicing on I see several 'system' accounts that have login capability including 'man' 'games' 'nobody' and others. I'd like to remove that ability to ensure that if any of these accounts were compromised (possibly deliberately by the malicious previous admin), the system isn't compromised. Doing a little research on the web it appears that at least some system accounts need login, or shell access. Is this true? Is there any way to determine which accounts need shell access? Or am I on the wrong track entirely, trying to do something that is not useful?

Thanks in advance for any help or advice.

JulianTosh 02-20-2009 10:35 PM

There are two files related to user accounts: passwd and shadow.

The shadow file holds the password hashes. If you look at the accounts You're concerned about ,you'll see !! and/or * in the 2nd ':' delimited field.

The !! means that the account is locked out.
The * means that the account is disabled.

so why are the accounts there if they are disabled or locked? Because root can still 'su' to the accounts to do nifty things like process isolation (somebody correct me on this if I got it wrong)... when the OS is coming up, it can fork off daemons to run services as those users, but they are effectively disabled from non-root access.

darin722 02-21-2009 05:56 PM

/etc/passwd and /etc/shadow
 
Quote:

Originally Posted by Admiral Beotch (Post 3451843)
There are two files related to user accounts: passwd and shadow.

The shadow file holds the password hashes. If you look at the accounts You're concerned about ,you'll see !! and/or * in the 2nd ':' delimited field.

The !! means that the account is locked out.
The * means that the account is disabled.

so why are the accounts there if they are disabled or locked? Because root can still 'su' to the accounts to do nifty things like process isolation (somebody correct me on this if I got it wrong)... when the OS is coming up, it can fork off daemons to run services as those users, but they are effectively disabled from non-root access.

Thanks, thats helpful. I think I already knew most of that but you definitely helped me put the two files together in a more consistent way. I'm still a little curious about how these two impact security, especially in the event that a system user such as 'nobody' or worse, some less tested application, becomes compromised.

Is it possible that having a shell set in field 7 of /etc/passwd would be a security problem even if /etc/shadow has a * or ! in the password field? is it appropriate for security purposes to set this field to /bin/false or /bin/nologin or will that potentially break the application? Is setting a * or ! in the password field of /etc/shadow sufficient to keep an attacker from doing bad things if they manage to compromise an application?

JulianTosh 02-21-2009 06:15 PM

The only way I can think of, off the top of my head, how those accounts can be compromised is through a vulnerability in the service that is running as them.

If that's the case, then the bad guys are already in the system but with non-root privileges.

You can't bruteforce your way into a shell with those accounts because they are locked or disabled and only accessible from the root account.

It seems to me that changing the shell to something other than a command interpreter would break whatever process that was using that account.

Bottom line is that I am pretty certain that these accounts are safe as is.


All times are GMT -5. The time now is 01:18 AM.