Security
  Home arrow Security arrow Page 9 - Unix Host Security: Hacks 11-20
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
SECURITY

Unix Host Security: Hacks 11-20
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 31
    2004-05-10


    Table of Contents:
  • Unix Host Security: Hacks 11-20
  • Prevent Stack-Smashing AttacksHack #12
  • Lock Down Your Kernel with grsecurity Hack #13
  • Restrict Applications with grsecurity Hack #14
  • Restrict System Calls with Systrace Hack #15
  • Automated Systrace Policy Creation Hack #16
  • Control Login Access with PAM Hack #17
  • Restricted Shell Environments Hack #18
  • Enforce User and Group Resource Limits Hack #19
  • Automate System Updates Hack #20

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    Unix Host Security: Hacks 11-20 - Enforce User and Group Resource Limits Hack #19
    ( Page 9 of 10 )

    Make sure resource-hungry users don’t bring down your entire system.

    Whether it’s through malicious intent or an unintentional slip, having a user bring your system down to a slow crawl by using too much memory or CPU time is no fun at all. One popular way of limiting resource usage is to use the ulimit command. This method relies on a shell to limit its child processes, and it is difficult to use when you want to give different levels of usage to different users and groups. Another, more flexible way of limiting resource usage is with the PAM module pam_limits.

    pam_limits is preconfigured on most systems that have PAM installed. All you should need to do is edit /etc/security/limits.conf to configure specific limits for users and groups.

    The limits.conf configuration file consists of single-line entries describing a single type of limit for a user or group of users. The general format for an entry is:

    domain type resource value

    The domain portion specifies to whom the limit applies. Single users may be specified here by name, and groups can be specified by prefixing the group name with an @. In addition, the wildcard character * may be used to apply the limit globally to all users except for root. The type portion of the entry specifies whether the limit is a soft or hard resource limit. Soft limits may be increased by the user, whereas hard limits can be changed only by root. There are many types of resources that can be specified for the resource portion of the entry. Some of the more useful ones are cpu, memlock, nproc, and fsize. These allow you to limit CPU time, total locked-in memory, number of processes, and file size, respectively. CPU time is expressed in minutes, and sizes are in kilobytes. Another useful limit is maxlogins, which allows you to specify the maximum number of concurrent logins that are permitted.

    One nice feature of pam_limits is that it can work together with ulimit to allow the user to raise her limit from the soft limit to the imposed hard limit.

    Let’s try a quick test to see how it works. First we’ll limit the number of open files for the guest user by adding these entries to limits.conf:

    guest soft nofile 1000
    guest hard nofile 2000

    Now the guest account has a soft limit of 1,000 concurrently open files and a hard limit of 2,000. Let’s test it out:

    # su – guest
    $ ulimit –a
    core file size (blocks, -c) 0
    data seg size (kbytes, -d) unlimited
    file size (blocks, -f) unlimited
    max locked memory (kbytes, -l) unlimited
    max memory size (kbytes, -m) unlimited
    open files (-n) 1000
    pipe size (512 bytes, -p) 8
    stack size (kbytes, -s) 8192
    cpu time (seconds, -t) unlimited
    max user processes (-u) 1024
    virtual memory (kbytes, -v) unlimited
    $ ulimit –n 2000
    $ ulimit –n
    2000
    $ ulimit –n 2001
    -bash: ulimit: open files: cannot modify limit: Operation not permitted

    There you have it. In addition to open files, you can create resource limits for any number of other resources and apply them to specific users or entire groups. As you can see, pam_limits is quite powerful and useful in that it doesn’t rely upon the shell for enforcement.



     
     
    >>> More Security Articles          >>> More By O'Reilly Media
     

       

    SECURITY ARTICLES

    - Critical Microsoft Visual Studio Security Pa...
    - US Faces Tech Security Expert Deficit
    - LAN Reconnaissance
    - An Epilogue to Cryptography
    - A Sequel to Cryptography
    - An Introduction to Cryptography
    - Security Overview
    - Network Security Assessment
    - Firewalls
    - What’s behind the curtain? Part II
    - What’s behind the curtain? Part I
    - Vectors
    - PKI: Looking at the Risks
    - A Quick Look at Cross Site Scripting
    - PKI Architectures: How to Choose One





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 2 Hosted by Hostway
    Stay green...Green IT