Re: Linux kernels DoSable by file-max limit

From: Michal Zalewski (lcamtufat_private)
Date: Mon Jul 08 2002 - 18:30:34 PDT

  • Next message: turambar386at_private: "iPlanet Remote File Viewing"

    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 [lcamtufat_private] [security]
    [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
    =-=> Did you know that clones never use mirrors? <=-=
              http://lcamtuf.coredump.cx/photo/
    



    This archive was generated by hypermail 2b30 : Tue Jul 09 2002 - 11:35:51 PDT