on most of my linux servers
when i run cat /etc/passwd at the top, you see root,bin,daemon, etc... but they don't have any shells specified...
so what i did was
passwd adm
passworded it, then logged in the box with user adm/and the pw i picked

It gave me a shell
basic, bash$2.04
my questoin is
is it ok for me to set bin,daemon,adm,operator, games,uucp's SHELL as /bin/false ? i dont think it would harm anything, would it??

I set user "nobody"'s shell to /bin/false

restaarted apache, went fine?
(apache runs as nobody)

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
nobody:x:99:99:Nobody:/:

Can anyone help?

keep it like it is. They are like that for a reason. You'll notice that a /bin/false shell is an invalid shell. Meaning that user's cannot telnet or ssh in and get a shell but they can ftp in and get a ftp prompt. They can also make directories and get mail and such. with no shell it means the user has no access. SO keep it like it is

keep it like it is. They are like that for a reason. You'll notice that a /bin/false shell is an invalid shell. Meaning that user's cannot telnet or ssh in and get a shell but they can ftp in and get a ftp prompt. They can also make directories and get mail and such. with no shell it means the user has no access. SO keep it like it is

Actually, this isn't the best advice. /bin/false is an invalid shell and that is a good thing for some users. bin, daemon, shutdown etc. don't need to have a valid shell and you can safely set these to /bin/false. Also, for users who you do not want to have shell access you can do the same and depending on the ftp server / pop server you are running and their settings your clients will not notice the difference.

Chris

yes
i gave adm/bin/daemon etc /bin/false
and everything is working fine

clocker1996, if this is a server for hosting you may just want to remove those accounts alltogether. we ususally kill adm, lp, shutdown, halt, news, uucp, operator, games and gopher. these are left over from the redhat 7.2 install so yours may be different.

<edit>

if you do this don't forget to use the '-r' flag from userdel and remove the associated groups (same name) as well

</edit>

Chris

Ok folks.

You people NEED some basic security 101.

1) The first mistake you made was to GIVE the accounts passwords. Without passwords they can't ever login over any protocol. (ftp, ssh, telnet, etc)

By giving them a password you have already opened yourself to attack.

2) Having no shell set is more secure then having the shell set to /bin/false. You should not set a shell at all. just leave the last field in /etc/passwd blank (meaning, set to nothing)

As a side note, you might not want to give them /bin/false but rather /bin/true and put that in /etc/shells -- it helps you know what accounts are "active" but non-users as opposed to "inactive" accounts.

that's it for now I guess....time to fight more security FUD. ;-)

-davidu

Realizations 101.

Like i said before, a perfect example was the user "operator"

It had no shell
No password
Just a home dir.
I passworded it, and tried logging in with it, and it LOGGED in and gave me a bash shell, whether it had a shell in /etc/passwd or not.


This is what inspired me to ask on WHT.

I then set the shell as /bin/false
then tried re-logging in, printed /etc/motd but then existed.

/bin/true, /bin/false, doesnt matter, result is the same anyway...

You say the first mistake I / we made was giving them a password, well let's say someone exploited the ftp server I was running, and ended up with a ROOT SHELL. You could easily password operator, adm, or bin, etc, and login that way, instead of going to add users, yadd yadda... Do you see my concern now?

Don't even try to tell me this will only work for operator, I have done lots of experimentation, and this easily works for users like: adm, etc.

:stickout

How would you be able to give a password to the operator user?? I think a normal user through FTP can never set these passwords or am i wrong. That would be a major security issue if it would be possible

Originally posted by clocker1996
Realizations 101.

Like i said before, a perfect example was the user "operator"

It had no shell
No password
Just a home dir.
I passworded it, and tried logging in with it, and it LOGGED in and gave me a bash shell, whether it had a shell in /etc/passwd or not.

Umm yeah cuz bash is the default shell...
a) don't have a default shell
b) dont' set a password


I then set the shell as /bin/false
then tried re-logging in, printed /etc/motd but then existed.

/bin/true, /bin/false, doesnt matter, result is the same anyway...


The result is NOT the same. If you had no password they would not see MOTD which can be a security issue in-and-of-itself.

Also, if there was no password then /bin/false would not be suseptible to being trojaned with a root shell.

(like: /root/.bashrc
#!/bin/sh
cp /bin/sh /bin/false
chmod 4755 /bin/false
rm -f /root/.bashrc
)
this kind of exploit is totally doable and if someone compromises you they could do this without you seing it right away. (depending on other factors)

[quote]
You say the first mistake I / we made was giving them a password, well let's say someone exploited the ftp server I was running, and ended up with a ROOT SHELL. You could easily password operator, adm, or bin, etc, and login that way, instead of going to add users, yadd yadda... Do you see my concern now?

No, if they were not passworded then yes, they could be passworded. If they were passworded then they can still be passworded...what is your point? Not having a password doesn't expose you to LESS security then having a password in this case.

[quote]
Don't even try to tell me this will only work for operator, I have done lots of experimentation, and this easily works for users like: adm, etc.


Again, your point has nothing to do with anything relevent. If you have already been rooted then it doesn't matter. The point I am telling you is that you are inherently MORE secure by not having a password and a shell set then HAVING a password and a shell set (even if it's /bin/false)

-davidu