shell damage - BSD

This is a discussion on shell damage - BSD ; Would a two line shell script that run as any local user uses all available CPU and Memory to the point that the box needs rebooting, be considered a concern. One one hand, they have local access, they are a ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: shell damage

  1. shell damage

    Would a two line shell script that run as any local user uses all
    available CPU and Memory to the point that the box needs rebooting, be
    considered a concern.

    One one hand, they have local access, they are a user, they should be
    trusted.

    On the other hand a user should not be able to affect the experience of
    another.

    The problems caused by users using all available disk space is the
    reason for disk partitions and quotas. Is CPU and Memory a similar
    resource? Are there limitations in the kernel? Should it be possible?

    I ask because I am surprised to be able to.

    Your thoughts are appreciated.
    Steve P


  2. Re: shell damage

    On Fri, 02 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    article <1194006174.30363.0@proxy00.news.clara.net>, Steve P wrote:

    >Would a two line shell script that run as any local user uses all
    >available CPU and Memory to the point that the box needs rebooting,
    >be considered a concern.


    It's called a "fork bomb" and it doesn't even have to be two lines.

    Web Results 1 - 10 of about 1,640,000 for fork bomb. (0.22 seconds)

    >One one hand, they have local access, they are a user, they should
    >be trusted.


    Like students?

    >On the other hand a user should not be able to affect the experience
    >of another.


    After you put a few severed heads on pikes out at the building
    entrances, the other users tend to get the word. You aren't allowed
    to do that? Read on.

    >The problems caused by users using all available disk space is the
    >reason for disk partitions and quotas. Is CPU and Memory a similar
    >resource? Are there limitations in the kernel? Should it be possible?


    The normal solution is that this is _usually_ handled at the shell
    level.

    >I ask because I am surprised to be able to.


    [compton ~]$ help ulimit
    ulimit: ulimit [-SHacdfmstpnuv [limit]]
    Ulimit provides control over the resources available to processes
    started by the shell, on systems that allow such control. If an
    option is given, it is interpreted as follows:

    -S use the `soft' resource limit
    -H use the `hard' resource limit
    -a all current limits are reported
    -c the maximum size of core files created
    -d the maximum size of a process's data segment
    -m the maximum resident set size
    -s the maximum stack size
    -t the maximum amount of cpu time in seconds
    -f the maximum size of files created by the shell
    -p the pipe buffer size
    -n the maximum number of open file descriptors
    -u the maximum number of user processes
    -v the size of virtual memory

    If LIMIT is given, it is the new value of the specified resource.
    Otherwise, the current value of the specified resource is printed.
    If no option is given, then -f is assumed. Values are in 1k
    increments, except for -t, which is in seconds, -p, which is in
    increments of 512 bytes, and -u, which is an unscaled number of
    processes.
    [compton ~]$

    That's a Bash shell, but the same command is in many Bourne style
    shells. See the man page for the shell. If you're a pervert and use the
    C shell or derivatives, see the 'limit' command in that shell.

    Old guy

  3. Re: shell damage

    On 2007-11-03, Moe Trin wrote:
    > On Fri, 02 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    > article <1194006174.30363.0@proxy00.news.clara.net>, Steve P wrote:
    >
    >>Would a two line shell script that run as any local user uses all
    >>available CPU and Memory to the point that the box needs rebooting,
    >>be considered a concern.

    >
    > It's called a "fork bomb" and it doesn't even have to be two lines.
    >
    > Web Results 1 - 10 of about 1,640,000 for fork bomb. (0.22 seconds)
    >
    >>One one hand, they have local access, they are a user, they should
    >>be trusted.

    >
    > Like students?
    >
    >>On the other hand a user should not be able to affect the experience
    >>of another.

    >
    > After you put a few severed heads on pikes out at the building
    > entrances, the other users tend to get the word. You aren't allowed
    > to do that? Read on.
    >
    >>The problems caused by users using all available disk space is the
    >>reason for disk partitions and quotas. Is CPU and Memory a similar
    >>resource? Are there limitations in the kernel? Should it be possible?

    >
    > The normal solution is that this is _usually_ handled at the shell
    > level.
    >
    >>I ask because I am surprised to be able to.

    >
    > [compton ~]$ help ulimit
    > ulimit: ulimit [-SHacdfmstpnuv [limit]]
    > Ulimit provides control over the resources available to processes
    > started by the shell, on systems that allow such control. If an
    > option is given, it is interpreted as follows:
    >
    > -S use the `soft' resource limit
    > -H use the `hard' resource limit
    > -a all current limits are reported
    > -c the maximum size of core files created
    > -d the maximum size of a process's data segment
    > -m the maximum resident set size
    > -s the maximum stack size
    > -t the maximum amount of cpu time in seconds
    > -f the maximum size of files created by the shell
    > -p the pipe buffer size
    > -n the maximum number of open file descriptors
    > -u the maximum number of user processes
    > -v the size of virtual memory
    >
    > If LIMIT is given, it is the new value of the specified resource.
    > Otherwise, the current value of the specified resource is printed.
    > If no option is given, then -f is assumed. Values are in 1k
    > increments, except for -t, which is in seconds, -p, which is in
    > increments of 512 bytes, and -u, which is an unscaled number of
    > processes.
    > [compton ~]$
    >
    > That's a Bash shell, but the same command is in many Bourne style
    > shells. See the man page for the shell. If you're a pervert and use the
    > C shell or derivatives, see the 'limit' command in that shell.
    >
    > Old guy

    I was under the impression /etc/login.conf could control this by
    limiting the maximum amount of processes a user could spawn.

    Am I wrong?


  4. Re: shell damage

    On Wed, 21 Nov 2007 08:07:02 +0000, Vlad D. Markov wrote:

    > I was under the impression /etc/login.conf could control this by
    > limiting the maximum amount of processes a user could spawn.
    >
    > Am I wrong?


    Well, if you need to be sure you can test it by entering the following at
    your shell prompt and hitting enter:

    ){ :|:& };:

    Warning: Don't do this if you have work unsaved or open databases!

  5. Re: shell damage

    On Wed, 21 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    article , Vlad D. Markov wrote:

    >On 2007-11-03, Moe Trin wrote:


    >> [compton ~]$ help ulimit


    >> That's a Bash shell, but the same command is in many Bourne style
    >> shells. See the man page for the shell. If you're a pervert and use
    >> the C shell or derivatives, see the 'limit' command in that shell.


    > I was under the impression /etc/login.conf could control this by
    > limiting the maximum amount of processes a user could spawn.


    [james-webb ~]$ whatis login.conf
    login.conf (5) - login class capability database
    [james-webb ~]$

    It certainly is on my FreeBSD systems, but the file isn't universal,
    whereas the 'ulimit' or 'limit' commands are found on virtually all
    systems that are not archaic..

    > Am I wrong?


    You're posting from what appears to be a SunOS box - and if that
    really is SunOS, I don't recall a login.conf file. It is available
    if you've installed PAM (certainly on Solaris and Linux), so it's
    hard to say.

    Old guy

  6. Re: shell damage

    On 2007-11-21, Moe Trin wrote:
    > On Wed, 21 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    > article , Vlad D. Markov wrote:
    >
    >>On 2007-11-03, Moe Trin wrote:

    >
    >>> [compton ~]$ help ulimit

    >
    >>> That's a Bash shell, but the same command is in many Bourne style
    >>> shells. See the man page for the shell. If you're a pervert and use
    >>> the C shell or derivatives, see the 'limit' command in that shell.

    >
    >> I was under the impression /etc/login.conf could control this by
    >> limiting the maximum amount of processes a user could spawn.

    >
    > [james-webb ~]$ whatis login.conf
    > login.conf (5) - login class capability database
    > [james-webb ~]$
    >
    > It certainly is on my FreeBSD systems, but the file isn't universal,
    > whereas the 'ulimit' or 'limit' commands are found on virtually all
    > systems that are not archaic..
    >
    >> Am I wrong?

    >
    > You're posting from what appears to be a SunOS box - and if that
    > really is SunOS, I don't recall a login.conf file. It is available
    > if you've installed PAM (certainly on Solaris and Linux), so it's
    > hard to say.
    >

    Yes I was posting from SunOS but I also have an OpenBSD box. login.conf
    is definitely a BSD-ism and it appears to work on my box. I've only seen
    login.conf on OpenBSD, FreeBSD, and NetBSD. We use ulimit for this on
    our linux boxes. I am just learning Solaris so I don't know about that
    one.

  7. Re: shell damage

    On Wed, 21 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    article <3a11j.79$lz.55@newsfe09.lga>, Vlad D. Markov wrote:

    >Moe Trin wrote:


    >> Vlad D. Markov wrote:


    >>> I was under the impression /etc/login.conf could control this by
    >>> limiting the maximum amount of processes a user could spawn.

    >>
    >> [james-webb ~]$ whatis login.conf
    >> login.conf (5) - login class capability database
    >> [james-webb ~]$
    >>
    >> It certainly is on my FreeBSD systems, but the file isn't universal,
    >> whereas the 'ulimit' or 'limit' commands are found on virtually all
    >> systems that are not archaic..


    I've seen arguments both ways as to which is a better way to put
    restrictions on resource use. "It depends".

    >> You're posting from what appears to be a SunOS box - and if that
    >> really is SunOS, I don't recall a login.conf file. It is available
    >> if you've installed PAM (certainly on Solaris and Linux), so it's
    >> hard to say.

    >
    >Yes I was posting from SunOS but I also have an OpenBSD box.
    >login.conf is definitely a BSD-ism and it appears to work on my box.
    >I've only seen login.conf on OpenBSD, FreeBSD, and NetBSD. We use
    >ulimit for this on our linux boxes. I am just learning Solaris so I
    >don't know about that one.


    Again - it depends. SunOS (up to version 4.1.4) is a BSD based
    operating system. Solaris (which officially began a version 5.0
    but is also known as v 2.0) is more SystemV based, though both
    have some warts from the "other" source. Depending on the age
    of the systems, a SunOS box _may_ have a /usr/5bin/ directory
    which has SysV binaries, and a Solaris box _may_ have a /usr/ucb/
    directory for BSD binaries. This used to drive me nuts when I was
    supporting both O/S. The usual solution was to have ~/.profile
    look at the uname output, and set the PATH accordingly so that
    the BSD based binaries were earlier in the PATH.

    For non-BSD systems, the key is often whether you have PAM installed
    and it is used by the mechanism/application you are using to log in. In
    that case, you _may_ have a /etc/login.conf, but it's just as possible
    that the resource limits might be in another file - perhaps
    /etc/security.conf, or /etc/security/limits.conf. The disadvantage
    of using PAM for resource limitation is that this requires the O/S
    kernel to have the necessary hooks for such restrictions. Not all
    do. In _that_ case, the 'ulimit' or 'limit' functions of the shell
    have to be used.

    Old guy

  8. Re: shell damage

    Mark South wrote:

    > On Wed, 21 Nov 2007 08:07:02 +0000, Vlad D. Markov wrote:
    >
    >> I was under the impression /etc/login.conf could control this by
    >> limiting the maximum amount of processes a user could spawn.
    >>
    >> Am I wrong?

    >
    > Well, if you need to be sure you can test it by entering the following at
    > your shell prompt and hitting enter:
    >
    > ){ :|:& };:
    >
    > Warning: Don't do this if you have work unsaved or open databases!


    ok, it seems this created a local DoS that locked my machine to the point of
    requiring a hard reboot.

    I am using a default install of Kubuntu feisty_fawn.

    I request advice on how to limit this from causing future problems...

    --
    I will not be pushed, filed, stamped, indexed, briefed, debriefed, or
    numbered!
    My life is my own - No. 6

  9. Re: shell damage

    On Thu, 22 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    article <2733543.VVIhKElGaq@rawgames.org>, Technomage Hawke wrote:

    >Mark South wrote:


    >> Well, if you need to be sure you can test it by entering the
    >> following at your shell prompt and hitting enter:
    >>
    >> ){ :|:& };:
    >>
    >> Warning: Don't do this if you have work unsaved or open databases!

    >
    >ok, it seems this created a local DoS that locked my machine to the
    >point of requiring a hard reboot.


    Yup - use your favorite search engine, and look for "fork bomb". It's
    a popular sport of college students trying to have fun by screwing up
    other students using the same computer. See what your current
    limits are by running the command 'ulimit -a'.

    >I am using a default install of Kubuntu feisty_fawn.


    That's a Linux, using the KDE desktop. You'd probably have better luck
    posting to the 'alt.os.linux.ubuntu' newsgroup. While there are a lot
    of similarities between OpenBSD and Linux, there are also some
    significant differences in the way things are implemented.

    >I request advice on how to limit this from causing future problems...


    1. Normal advice would be to set ulimit in '/etc/profile' but
    2. Using a GUI login usually runs a display manager (probably kdm) in
    place of the normal login scripts. This _could_ be 'Xstartup'.
    3. This might also be controlled by '/etc/login.defs' if it exists.
    4. If all else fails, this can be set in .bashrc in your home directory.

    What you want to do is to limit the number of processes. First, as a
    user, run the command 'ps | wc -l' to see how many processes you are
    _normally_ running. For example

    [compton ~]$ ps |wc -l
    51
    [compton ~]$

    Now, you want to set 'ulimit -u' to something beyond that. The syntax
    would be

    ulimit -u 128

    Look at the four files mentioned above, and see if there is a 'ulimit'
    command already there (perhaps with different options). Add this line,
    log out, log back in, and run 'ulimit -a' to see if the change has
    taken effect. See the man page for 'ulimit' for further details
    and other resource limits.

    Old guy

  10. Re: shell damage

    Moe Trin wrote:

    > On Thu, 22 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc,
    > in article <2733543.VVIhKElGaq@rawgames.org>, Technomage Hawke wrote:
    >
    >>Mark South wrote:

    >
    >>> Well, if you need to be sure you can test it by entering the
    >>> following at your shell prompt and hitting enter:
    >>>
    >>> ){ :|:& };:
    >>>
    >>> Warning: Don't do this if you have work unsaved or open databases!

    >>
    >>ok, it seems this created a local DoS that locked my machine to the
    >>point of requiring a hard reboot.

    >
    > Yup - use your favorite search engine, and look for "fork bomb". It's
    > a popular sport of college students trying to have fun by screwing up
    > other students using the same computer. See what your current
    > limits are by running the command 'ulimit -a'.
    >

    yeah. there isn't any difference in that command from Unix (BSD) and Linux
    (Feisty_fawn). it should yield usable output for me here.
    I run OpenBSD on virtual hardware (vmware) and oft times use it as my
    network's firewall of choice (thank you PF).

    >>I am using a default install of Kubuntu feisty_fawn.

    >
    > That's a Linux, using the KDE desktop. You'd probably have better luck
    > posting to the 'alt.os.linux.ubuntu' newsgroup. While there are a lot
    > of similarities between OpenBSD and Linux, there are also some
    > significant differences in the way things are implemented.
    >

    I hardly ever get good answers there. it seems the trolls have taken over
    and now we hear windows V. Linux all the time. S/N ratio too low for useful
    conversation.

    >>I request advice on how to limit this from causing future problems...

    >
    > 1. Normal advice would be to set ulimit in '/etc/profile' but

    check...

    > 2. Using a GUI login usually runs a display manager (probably kdm) in
    > place of the normal login scripts. This _could_ be 'Xstartup'.

    check, though in Kubuntu, its Xsession

    > 3. This might also be controlled by '/etc/login.defs' if it exists.

    does not appear on my kubuntu or other late model linux systems.

    > 4. If all else fails, this can be set in .bashrc in your home directory.

    usually last resort. problem is, allowing it to be read and not modified by
    the user that owns it (perms problem).

    >
    > What you want to do is to limit the number of processes. First, as a
    > user, run the command 'ps | wc -l' to see how many processes you are
    > _normally_ running. For example


    >
    > [compton ~]$ ps |wc -l
    > 51
    > [compton ~]$

    interesting, mine kicks out 4

    >
    > Now, you want to set 'ulimit -u' to something beyond that. The syntax
    > would be
    >
    > ulimit -u 128

    tried that, it reverted back to unlimited
    could be a setting I have to look at (command syntax?).

    >
    > Look at the four files mentioned above, and see if there is a 'ulimit'
    > command already there (perhaps with different options). Add this line,
    > log out, log back in, and run 'ulimit -a' to see if the change has
    > taken effect. See the man page for 'ulimit' for further details
    > and other resource limits.

    ok, useful advice - thanks
    I'll do some further checking on other problems here as well.

    >
    > Old guy


    --
    I will not be pushed, filed, stamped, indexed, briefed, debriefed, or
    numbered!
    My life is my own - No. 6

  11. Re: shell damage

    On Sun, 25 Nov 2007, in the Usenet newsgroup comp.unix.bsd.openbsd.misc, in
    article <2178863.kxgDUrdTZx@rawgames.org>, Technomage Hawke wrote:

    >Moe Trin wrote:


    >> See what your current limits are by running the command 'ulimit -a'.

    >
    >yeah. there isn't any difference in that command from Unix (BSD) and
    >Linux (Feisty_fawn). it should yield usable output for me here.
    >I run OpenBSD on virtual hardware (vmware) and oft times use it as my
    >network's firewall of choice (thank you PF).


    Problem - 'ulimit' is a shell command. If limits aren't set in the
    shell, they shouldn't show here.

    >> That's a Linux, using the KDE desktop. You'd probably have better
    >> luck posting to the 'alt.os.linux.ubuntu' newsgroup.


    >I hardly ever get good answers there. it seems the trolls have taken
    >over and now we hear windows V. Linux all the time. S/N ratio too low
    >for useful conversation.


    Yeah, I know what you are saying - I've got a fairly harsh killfile
    to improve the S/N ratio.

    >> 1. Normal advice would be to set ulimit in '/etc/profile' but


    >check...


    >> 2. Using a GUI login usually runs a display manager (probably kdm) in
    >> place of the normal login scripts. This _could_ be 'Xstartup'.


    >check, though in Kubuntu, its Xsession


    Gotta love the standards ;-) I'm told that Mandriva 2008.0 is now
    sourcing the shell startup scripts out of the desktop manager start
    scripts. Hey, it's only been 20 years.

    >> 3. This might also be controlled by '/etc/login.defs' if it exists.


    >does not appear on my kubuntu or other late model linux systems.


    I think it depends on the version of PAM used.

    >> 4. If all else fails, this can be set in .bashrc in your home directory.

    >
    >usually last resort. problem is, allowing it to be read and not modified
    >by the user that owns it (perms problem).


    One way around that is to have the sticky bit set in the directory
    (or in Linux, use 'chattr' to make the file immutable), have root own
    that file, and include a

    [ -s /home/$LUSER/.bashrc.luser ] && . /home/$LUSER/.bashrc.luser

    or similar. Yes, that is subject to abuse too.

    >> [compton ~]$ ps |wc -l
    >> 51
    >> [compton ~]$


    >interesting, mine kicks out 4


    [compton ~]$ ps | wc -l
    38
    [compton ~]$ ps | grep -cw bash
    21
    [compton ~]$

    Lots of open terminals - running a bunch of command processes.

    >> Now, you want to set 'ulimit -u' to something beyond that. The syntax
    >> would be
    >>
    >> ulimit -u 128


    >tried that, it reverted back to unlimited


    [compton ~]$ ulimit -u
    128
    [compton ~]$ ulimit -u 120
    [compton ~]$ ulimit -u
    120
    [compton ~]$ ulimit -u 128
    [compton ~]$ ulimit -u 140
    ulimit: cannot raise limit: Operation not permitted
    [compton ~]$

    Here, the system is hard-limited to 128. I can set it lower, or raise it
    back up to the hard limit.

    >could be a setting I have to look at (command syntax?).


    Where did you run the command? Setting the limit only effects "this" and
    and child processes. Look at the output of 'ps afuwx' and see which part
    of the mess you are effecting. I'm using X here, but that's run from a
    text login (via 'runx'). I don't use a GUI login, so the first process
    that has my name on it is the login shell - not a desktop manager or
    similar. Another problem is that *buntu is (I believe) running a
    security nanny program to reset permissions/ownerships and the like -
    to protect the silly users from themselves.

    Old guy

+ Reply to Thread