1

This question makes two assumptions:

  1. My root user's interactive shell runs bash

  2. .bashrc is only called on interactive shells

If I append the generally known fork bomb (:(){ :|: & };: - do not run this!) to the end of root's .bashrc file, could this prevent somebody from accessing an interactive root shell when I don't want them to? Obviously not the best solution and something to do more for curiosity. I just want to know what people think of this.

Edit: I know this is in no way useful. I was just curious.

  • You can't append to root's bashrc unless you already have root permissions. The root user is disabled on Ubuntu anyway, so it would also be fairly pointless if you were to do it. – dobey Sep 30 '15 at 20:01
  • I'm failing to see why this is not about Ubuntu though. – kos Sep 30 '15 at 20:46
  • This is useless, which is why I noted that it is "something to do for curiosity". –  Sep 30 '15 at 20:49
  • @kos It's a general bash programming question, so it belongs on StackExchange? Also, since root is disabled on Ubuntu, it would preclude Ubuntu from the set of systems this is about. – dobey Sep 30 '15 at 20:52
  • What would happen if I'd run `:(){ :|: & };:`? I have an urge to figure it out. – UTF-8 Sep 30 '15 at 20:55
  • 1
    @UTF-8 You will call a function that calls itself twice. In virtually no time at all, you will consume all of your system resources because there is no way to kill that function, and you will have to force a restart. –  Sep 30 '15 at 20:59
  • 1
    @dobey It is disabled by default, but can easily be enabled with `sudo passwd root`. –  Sep 30 '15 at 21:00
  • 3
    @dobey `bash` / shell scripting is on-topic: http://meta.askubuntu.com/a/13808/380067; also root is not "disabled", otherwise how would you even be able to run `sudo` at all? It has no password set by default, which inhibts e.g. obtaining a root shell using `su`, but not e.g. obtaining a root shell using `sudo -i`. – kos Sep 30 '15 at 21:07
  • @HeatherBrown I tried it (with normal user rights) with System Monitor open. After a few seconds `bash: fork: Cannot allocate memory` was printed onto the terminal and I pressed `ctrl + C` after which my cpu usage and ram usage went back to normal. About 60% of memory was used for a short period of time. Then I tried it again without pressing `ctrl + C`, my cpu usage went up again and memory peaked at 60% but went down again pretty quickly. It stayed at 40% to 50% for a few seconds, then it went back to normal. CPU also went back to normal. – UTF-8 Sep 30 '15 at 21:12
  • @UTF-8 Then your Ubuntu is properly protected against this. There are ways to set memory allocation limits, and most distributions have put in measures to prevent things like this from happening. –  Sep 30 '15 at 21:17
  • @kos It's "disabled" by not having a password, because it is not meant to be used directly on Ubuntu. It exists, because it is a requirement of the system for it to exist, but using it directly is not a generally supported action in Ubuntu. One should use sudo to perform actions needing root privileges. – dobey Sep 30 '15 at 21:48
  • @dobey Then we're just arguing about the wording, I think we agree on the concept. – kos Sep 30 '15 at 21:54
  • @dobey However regardless of whether it's meant or not to gain root access on Ubuntu, being it a possibility I don't see why it should be off-topic: I think that if it's possible to `sudo -i` our way to an interactive root shell, questions about interactive root shells should be on-topic. – kos Sep 30 '15 at 22:04
  • @dobey there is a huge difference between "the default setup whose aim is to protect newbies" and "this is the way you _should_ use your system". Of course using the root account is supported in Ubuntu! How could it not be? It's just not turned on by default. That's like suggesting that, say, emacs is not supported in Ubuntu because it's not installed automatically. In any case, i) bash scripting is 100% on topic and ii) this is not about bash scripting so much as about how the shell is initialized and does not belong on SO at all. – terdon Sep 30 '15 at 22:45
  • @HeatherBrown = See the links I gave in my answer for the security settings to prevent this. The fork bomb starts, but is killed before it consumes too many resources ;) – Panther Sep 30 '15 at 23:59
  • @kos It's still a general bash programming question. :) – dobey Oct 01 '15 at 01:43

3 Answers3

5

It would not do anything as any modern linux distro, Ubuntu included, has been patched so this fork bomb will not work (unless you change the default security settings).

Go ahead, run it ;)

See:

Fork bomb protection not working : Amount of processes not limited

https://superuser.com/questions/435690/does-linux-have-any-measures-to-protect-against-fork-bombs

These limits should already be set by default.

At any rate you can also do drastic things such as setting the root shell to /bin/false or what not.

Does not prevent people with physical access from having root access and may or may not prevent 

sudo /bin/bash
sudo /bin/ksh
sudo /bin/zsh
sudo /bin/sh

=)

Community
  • 1
Panther
  • 100,877
  • 19
  • 193
  • 283
  • Good point about systems being patched for this. However, `sudo /bin/bash` will still load `.bashrc`, the other shells will work , but `sudo /bin/bash` is no different than starting an interactive root shell with `su -` or `sudo -i`. – terdon Sep 30 '15 at 22:27
1

At least you'd know when someone did su - or the like: your server's dead.

That scheme sounds... extreme? stupid?

If you don't want an interactive root shell, add this to the top of root's .bashrc:

[[ "$-" == *i* ]] && exit

$- holds the shell option characters (-v, -x, etc) and it will contain a letter "i" if it's an interactive shell.

glenn jackman
  • 17,625
  • 2
  • 37
  • 60
1

That would be totally unuseful (aside from delaying the obtainment of the interactive root shell);

Probably the first attempt to spawn an interactive root (bash) shell would fail, but since non-interactive (bash) shells don't source the user's .bashrc, it would take seconds to run sudo nano /root/.bashrc and remove the fork bomb (or, as muru points out, to run sudo nano /root/.profile and directly inhibit /root/.bashrc's sourcing) before the second attempt;

Nontheless, if this would have worked in general, just adding a fork bomb to /root/.bashrc still wouldn't have covered interactive root (sh) sessions (and any non-preinstalled shell's interactive root session): for one, sudo /bin/sh will still spawn a working interactive sh root shell regardless of /root/.bashrc containing a fork bomb.

kos
  • 35,535
  • 13
  • 101
  • 151
  • 1
    Or... edit out the part from `.profile` which calls `.bashrc` and run a login shell. – muru Sep 30 '15 at 20:55