On Mon, 8 Jul 2002, Kurt Seifried wrote: > For example you can limit the amount of memory that user "bob" is allowed to > use: > > user hard memlock 4096 Uhhh... not quite. Linux kernel does not really provide a nice way of enforcing per-user limits by default, IIRC (unless something changed in last few years ;-). Both PAM and 'ulimit' share essentially the same interface, setrlimit(), that is mostly per-process, not per-user. Some PAM extensions (such as the maximum number of logins) are enforced on a per-user basis on a completely different layer. Even if you use PAM to set a "memory limit for a group 'students'", you are essentially setting a memory limit for each process of every person logged in that belongs to this group. And they can still most likely bypass your limit by putting something smart in their .procmailrc / .forward / .qmail, or in so many other ways. Linux limits are basically intended to prevent accidents from happening (such as some clueless user testing the code I have in my signature, why not... or a mail client gone bad and eating up all memory). There is very little you can do to change unless you make some serious redesign and very precise kernel and user-space time and resource control (with something like per-user-per-day CPU time / file usage / memory usage limits, peak usage limit, limits for whole groups of users, etc). In general, the reasonable assumption is that your *users* would prefer to use the system instead of rendering it unusable. If you have some mission critical tasks on the same machine as some potentially malicious users, split it into two separate boxes - simple. And on the box where you have malicious users, deploy some fair time and resource sharing (perhaps a VM?;) or simply restrict their rights to a very basic set of tools. > core files can be created when a program crashes. They have been used in > security exploits, overwriting system files, or by containing sensitive > information (such as passwords). Hm, yes and no. Linux behaves pretty well when it comes to core files - privileged programs generally don't drop cores, cores don't follow symlinks, etc, etc. > Bash has built in limits, accessed via "ulimit". Any hard limits cannot be > set higher, so if you have limits defined in /etc/profile, or in the users > .bash_profile (assuming they cannot edit/delete .bash_profile) you can > enforce limits on users with Bash shells. Even if I do 'ssh user@host bash --norc --noprofile'?:-) -- _____________________________________________________ Michal Zalewski [lcamtuf@bos.bindview.com] [security] [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: =-=> Did you know that clones never use mirrors? <=-= http://lcamtuf.coredump.cx/photo/
