I’m writing a BBS client and server on my Linux box (RedHat 7.2), and I’ve put this .cshrc file in /etc/skel:
/path/to/chat/client
exit
the idea being to automatically start the program when the user logs in, and automatically log them off when they exit the program. My question is, is this a major security flaw? Is it so easy to circumvent that any script kiddie with a brain stem can wreak havoc on my system? Needless to say, I’m not a security guru, so any relevant input is much appreciated.
I’m no expert either, but I think it may be more secure to specify the BBS client as the login shell in /etc/passwd. That way the chat client will not be running on top of an interactive shell.
Depends on the chat client. Several of them let you break out into a shell. There are other tricks you could do too, like downloading something new via DCC to your .bashrc file that lets you execute whatever commands you like.
I second this recommendation. You might also want to remove pretty much everything else from /etc/shells and double check to make sure there aren’t any security advisories out on whatever chat client you’re using. If you can run it in a chroot jail as well, then all the better.
Maybe I didn’t make myself entirely clear, or perhaps I don’t understand where you’re coming from - you warn me about the dangers of some clients being able to break out into the shell, or DCC into the dot files, and tell me I should check for security advisories. Are you talking about the BBS client I’m writing from scratch? If so, how does this apply? If not, what ARE you talking about?
In any case, I appreciate the info. I hadn’t considered making it the default shell, it seems like a good idea. TeleTronOne, if I took everything else out of /etc/shells, wouldn’t that interfere with root logging in? Or does it not work that way?
Commenting only on the specific OP, the answer is to do as others have said, and run the client as the default shell. This prevents the (small but present) possibility that someone will be able to exploit the running csh. As to the rest of it: Look carefully at the program you’re using, make certain there aren’t any known exploits that can’t be prevented, and run the program itself as a privelege-managed user , in a chrooted environment. There are other things you can do to make the OS itself less prone to attack, but hopefully you’ve already read up on that subject.
I’m sorry, I hadn’t completely understood what you were asking. Obviously, there shouldn’t be any active security avisories for a piece of software you haven’t written yet
As for the /etc/shells thing, it will work on FreeBSD (at least on 4.7-STABLE) in it’s default configration. I think there’s a PAM configuration option you can set on your average Linux distribution to preform the extra /etc/shells check on login - but I don’t have a Linux box handy at the moment, so I could be wrong.
I’m not sure precisely how you’re planning on setting things up, but you might want to make the home directories for this account(s) read-only. You can block out several commonplace attacks/tricks if there’s no way to get to your dotfiles. Of course, if somebody tries to “+ +” their .rhosts and you have rsh turned off anyway, it’s not going to matter much. But better safe than sorry if it’s something you’re really worried about.
Yeah, I’ve already turned off every service I don’t need, except the ones whose functions I don’t know. My goal is to have a very barebones system, with only necessary services and openSSH running.
Speaking of which, is there some place that explains what all those esoterically named services do?
