grsecurity forums

every one has a shell on the Linux boxs will crash the machine,as following:

main(void)
{
char *p;
while(1)
{
p = new char[1024];
fork();
}
}

limits.conf cann't do it work;when i use ulimit,the user can change there shells and do the same thing!!
anyone can give some suggestion?
thanks

dirls028 wrote:every one has a shell on the Linux boxs will crash the machine,as following:

main(void)
{
char *p;
while(1)
{
p = new char[1024];
fork();
}
}

limits.conf cann't do it work;when i use ulimit,the user can change there shells and do the same thing!!
anyone can give some suggestion?
thanks

Ban the users running that program? Even if you configure the system to prevent the problem described above, there're plenty of other ways for a user with shell access to be annoying and disruptive. While it's certainly nice to limit the damage that users can do (whether maliciously or accidentally), it's rarely worth the trouble to try to provide service to users who're intentionally trying to cause problems.

mikeeusa wrote:KP: if that were a valid solution wonderful things like grsecurity would be superfluous.
There should be a way of limiting this kind of thing.

Not at all. The user(s) causing problems have accounts on his system, and (assuming no directives from management to the contrary) those accounts can be revoked if the users continue to cause problems. Users performing DoS attacks remotely (e.g. attacking a webserver) can spoof their addresses, use zombies, etc. Such techniques make it difficult to reliably ban an attacker. None of those are a concern here, since the offending user(s) can be locked out simply by resetting authentication credentials (password, ssh keys, etc.), setting the user shell to /bin/false, and killing anything already running as that user.

GRsecurity is excellent for locking down the system to prevent users from getting into places they shouldn't be, whether they're exploring via shell accounts or attacking buggy daemons. Although you could certainly try to limit DoS attacks via GRsecurity policy, it seems to be much more oriented towards blocking & containing exploits.

To the original poster: you might be able to curb this by having sshd use setrlimit(2) to set a hard limit on number of processes (to block a fork(2) bomb) and on total data size (to block memory exhaustion) before it execs the user's shell. You may need to recompile sshd to achieve this. Beware that all users who log in through such a daemon will be stuck with the limits you choose.

mikeeusa wrote:How does one set these limits in ssh? Do you set something in the config file? (I've googled and turned up nothing). What are good defaults for the data one?

I don't know that there's any configuration option to set them. It may be necessary to add the appropriate calls to the source and recompile it. If so, look for calls to the set*id family of functions, since that'll be happening close to where the sshd is about to spawn a user's shell. A quick run through the source shows that finding this isn't as easy as I'd expected. I'd guess that placing the new calls in do_exec will have the desired effect. You could verify this by running the candidate sshd on an alternate port, logging in through it, and then checking the limits imposed upon that login. Note that most shells show soft limits by default, whereas I've been advocating a hard limit.

The data limit will vary depending on what the users are supposed to be running. I tend to like setting a data limit to be no more than system physical memory. However, Java virtual machines are absolute memory hogs, and often will not run under such a limit. Some heavy data-processing software may also chafe under such limits. If you're unsure, you could try setting a limit in the systemwide profile directory, and include instructions to report programs which fail under the limit you've set. You could make it a soft limit so that the users can raise it up without waiting for a response. Once you've run long enough that you're comfortable all the users' programs will work with that limit, build it into the sshd.

Note that the user can bypass both hard and soft limits in the system profiles, so it's best to use that only when testing. For instance, ssh -t mike-host.localdomain tcsh -f would allocate a terminal (-t), not be a login shell (no -l), and skip all profile files (-f).

to all:thank you for your suggestions.
my linux server have three accounts(me,teacher,stu),the stu account should be limited(handreds of students use the same account stu,so i don't known who will DoS my server),and the other two should not be limited.

at first,i think the config file /etc/security/limits.conf(Linux) will work as well as /etc/login.conf(on FreeBSD platform),but when i try that forkbomb program on linux,the server will crash within 5 seconds!

using telnet,x-win32,or ssh the user can login my server,i use profile to limit the stu account and let stu account cann't change their shell,that worked!
but it not a good solution,have another suggestions?
thanks

dirls028 wrote:to all:thank you for your suggestions.
my linux server have three accounts(me,teacher,stu),the stu account should be limited(handreds of students use the same account stu,so i don't known who will DoS my server),and the other two should not be limited.

Since you are probably using grsecurity, have you thought about TPE?

Before they can try to crash your server using a script they have start the script. They can't start it if they are not allowed to start programs outside the normal path's.

Servers which allow users to start programs they compiled themselves are much harder to secure. Probably those students need a compiler?

I suppose you already activated the execve_limiting option and extended logging for the most probable failures.

Kp wrote:

mikeeusa wrote:How does one set these limits in ssh? Do you set something in the config file? (I've googled and turned up nothing). What are good defaults for the data one?

I don't know that there's any configuration option to set them. It may be necessary to add the appropriate calls to the source and recompile it.

Or via PAM.

Code: Select all

# ldd /usr/sbin/sshd |grep pam
        libpam.so.0 => /lib/libpam.so.0 (0xb7f41000)
# grep limits /etc/pam.d/ssh
session    required     pam_limits.so
# _


Thanks to all of you
now i have two ways to limit the users

first,use /etc/profile
if [ $USER == "the-user-name" ]; then
ulimit -u 100
ulimit -m 50000
fi
i also changed chsh,let the user cann't change their shell


second,use /etc/security/limits.conf
* soft core 0
* hard rss 10000

and the /etc/ssh/sshd_config should add this line:UsePAM yes,otherwise the limits.conf will not work when the user use ssh terminal

but that will not always work on particular condition.

yes,may be grsec should add this function to it

dirls028 wrote:yes,may be grsec should add this function to it

it'd be a pointless exercise, as Andrew Morton put it a year ago:

But there are so many ways to cripple a Linux box once you have local
access. Another means which happens to be bug-induced doesn't seem
important.

for full context see http://marc.theaimsgroup.com/?l=linux-kernel&m=110558820820076&w=2