Questions on config files and security rules

All, I have a few questions about some system configuration files and required local security.

Is there any reason why /usr/bin/nologin is not in /etc/shells? Will it cause any problem to add it to the file?

Is there any reason why a user would need read access to files in /etc/xinetd.d? Would it cause a problem to remove read access?

Will it hurt anything to change the shell from /bin/bash to /usr/bin/nologin on the systems accounts (at, bin, daemon, ftp, games, ldap, lp, man, news, uucp)?

Thanks in advance.

Dave W

Generally speaking…

I don’t know if there is ever a single, “best” place for many files. Someone just makes a decision and from then on it becomes standard for that distro. This is likely how different distros come to have different sub-system layouts. Distro have different file locations but in the end all typically deliver a similar end result to the User.

I do think you should think twice before moving any files from one location to another for maintenance reasons. If a security modification/update is pushed by Maintainers, they will assume that files are in standard locations. If the modification affects your file, it won’t be found if you move it.

I’d probably also recommend thinking carefully about making low level security modifications you’re considering for the same reason.

If you want to make custom security changes, I’d recommend taking a look at higher level security based on policy like SELinux and AppArmor (both implemented by default on openSUSE) before doing anything else (You can still make your custom changes but document well and you’ll likely have to be ever vigilant about your changes later).


Like said above. Be very careful in changing those age old situations. When we take lp as example, you will never know for sure if a change of the login shell for user lp will hurt something (e.g. a functionality within the printing system that uses lp’s default shell for doing something) except when it breaks. The then you will know for sure of course, but you will never know if that happens rightout, or only after a year (with some update or configuring a special printer function).

And what is the gain? The user lp is already not able to login because it has no usable password.

Thanks for the reply, but I am not trying to move the file. /etc/shells is a security file, it tells the system what shells are valid for /etc/passwd. I was asking if nologin should be added to the file.

Most of the permission changes I make get undone by updates.

The scripts I wrote to make the changes for me always backup the current file before the change.

Dave W

The problem I have is the complete ignorance in the people that approve the scan reports. They do not understand that other things block those accounts from login on. They only understand that the report says that the accounts are active because they have shells. That is what you get when you hire people to be computer security experts that were never a SysAdmin.

Dave W.

Oops. that is very bad. I have my own experiences on this subject.

I am afraid that nothing will teach them, because they have read some statements somewhere and now think they are security experts.

Only thing I can say is that our advice (tsu2’s and mine) points to NOT change things at random, but study system hardening documents. And eventualy use tools (as tsu2 mentioned) and maybe the security levels that YaST > Security offers. Bu the results in most cases will be that either the system becomes unworkable for the things it is to be used for, or it will be more open then before.

And please take notes about every step you take.

Best wishes,