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.

Improve this question
16
  • 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
  • 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. – user323419 Sep 30 '15 at 20:59
  • 1
    @dobey It is disabled by default, but can easily be enabled with sudo passwd root. – user323419 Sep 30 '15 at 21:00
  • 3
    @dobey bash / shell scripting is on-topic: 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
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

=)

Improve this answer
1
  • 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.

Improve this answer
1
  • 2
    dose not prevent sudo sh – Panther Sep 30 '15 at 20:18
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.

Improve this answer
1
  • 1
    Or... edit out the part from .profile which calls .bashrc and run a login shell. – muru Sep 30 '15 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy