User security

M

MJennings

Hi guys. I'm looking to do a few things to secure my users. I would like to lock them in their home directories, I have heard this is kinda easy. Can someone point me in the right direction?

The second thing is that I would like to limit the number of processes they run under their usernames, is there a way to limit their processes to 20 (and exclude bash if possible)?
 
MJennings said:
Hi guys. I'm looking to do a few things to secure my users. I would like to lock them in their home directories, I have heard this is kinda easy. Can someone point me in the right direction?
Click to expand...
Do you want them to not be able to see/enter other user's directories or more?

The second thing is that I would like to limit the number of processes they run under their usernames, is there a way to limit their processes to 20 (and exclude bash if possible)?
Click to expand...
See login.conf(5).
 
Yes I would like them to not be able to see inside other home dirs or even see what's inside /home. I really don't even want them to see inside dirs in /usr or /var that they don't NEED to see
 
MJennings said:
Yes I would like them to not be able to see inside other home dirs or even see what's inside /home.
Click to expand...
User accounts are normally created like NameA:NameA. Just setting the permissions on those directories to 750 will prevent anyone else from getting in.


I really don't even want them to see inside dirs in /usr or /var that they don't NEED to see
Click to expand...
Same deal with /var. Just set the permissions correctly. Be carefull with /usr though. Users do need access to it to be able to execute commands. As for config files in /usr/local/etc, same deal. Just set the correct permissions.
 
You didn't tell us how your users are connecting. SSH? FTP? These have chroot options.
 
try rbash, it will take sometime to configure it, but it restricts well :) Don't forget to "secure" vi and pine as well, because users are able to execute commands via vi and pine.
 
If I was going to use the ChrootDirectory option on ssh, I would have to put all the binaries that I want everyone to access in their home directories? And I tried this
Code: 
ChrootDirectory /home/%u
and I got this in my auth.log
Code: 
fatal: bad ownership or modes for chroot directory "/home/testing"
 
Also how do I secure vi and pine? just change perms so users can't run them? and maxproc in login.conf works well.. but is there any way to make maxproc apply to everything except bash/sshd processes? or is there another way entirely to limit processes?
 
MJennings said:
Also how do I secure vi and pine?
Click to expand...
What's there to secure? The only reason vi would be a security risk is when you allow someone to sudo vi (vi allows the spawning of a shell). Sudoedit can be used instead of vi (which basically runs vi in secure mode).
 
ok. thanks for info. anyone know the answer to the second part of my question? about the maxproc on limit.conf
 
Does anyone have any ideas on how I would start writing a bash script or something for cron where I could just add usernames, and process limit for each and it would grep -v (sshd|bash|sftp-server) and then kill anything more than their limit? I could probably write the script for one user's limits but not for multiple :\
 
Don't kill running tasks from your users. You will not make yourself any popular by doing that.
 
Ok, well maybe not kill. But at least send them a warning local mail or something for the next time they login. How can I do this?
 
Perhaps you are looking for login.conf(5):
Code: 
DESCRIPTION
     login.conf contains various attributes and capabilities of login classes.
     A login class (an optional annotation against each record in the user
     account database, /etc/master.passwd) determines session accounting,
     resource limits and user environment settings.  It is used by various
     programs in the system to set up a user's login environment and to
     enforce policy, accounting and administrative restrictions.  It also pro-
     vides the means by which users are able to be authenticated to the system
     and the types of authentication available.  Attributes in addition to the
     ones described here are available with third-party packages.
 
I don't think you read the thread. I have been using login.conf, but it isn't working for me because maxproc counts everything (sshd, bash) and I need it to exclude those. So my idea is to write a script that will count processes and exclude the ones I don't want. And send warning message to user. I have seen this used on other servers.
 
MJennings said:
I don't think you read the thread. I have been using login.conf, but it isn't working for me because maxproc counts everything (sshd, bash) and I need it to exclude those. So my idea is to write a script that will count processes and exclude the ones I don't want. And send warning message to user. I have seen this used on other servers.
Click to expand...

To be honest, limiting the number of processes it not the correct way of going at this. I'm guessing that you don't want one user eating up most of the resources from the others and in that aspect the number of processes can be misguided. I can for instance have 25 processes (excuding ssh/shell) but they can all be idling and not using much CPU or memory, and one user might run folding@home/seti@home and user 60-70% CPU on just one process and most of the RAM.

So in limiting the available resources I would say if one user uses 70% CPU over a long period of time, this the one you should be after. How to do this I'm not completely sure, but there surly is some monitoring software in ports for CPU/Memory/Swap that can include the username as a variable.
 
MJennings said:
If I was going to use the ChrootDirectory option on ssh, I would have to put all the binaries that I want everyone to access in their home directories? And I tried this
Code: 
ChrootDirectory /home/%u
and I got this in my auth.log
Code: 
fatal: bad ownership or modes for chroot directory "/home/testing"
Click to expand...


try
Code: 
ChrootDirectory %h
 
You must log in or register to reply here.
Back
Top