Sandboxing your network software for Linux programmers, part 1

Discussion in 'privacy technology' started by Stefan Froberg, Jan 14, 2018.

  1. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    Code:
    https://www.orwell1984.today/Sandboxing_network_software_for_Linux_programmers_part1.pdf
    
     
  2. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    1,999
    Location:
    Member state of European Union
    When it comes to chroot one needs to remember to not hold any handle/file descriptor to something on filesystem outside of chroot. If you:
    1. grab file descriptor outside of chroot
    2. then chroot (descriptor will not close)
    3. you can escape chroot using that file descriptor
    At the same time it can be useful for somebody in need of exactly one IPC connection (through Unix domain sockets or TCP), but want to drop rights to open second IPC connection.
    It also works in similar manner in *BSD families of OSes.

    OpenBSD does not have namespaces, but has pledge(2) system call to easily restrict process rights.
     
  3. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Thanks @Stefan Froberg - to make sure I understand what this is doing, it's a guide for software application authors to do what even major applications fail to do - set themselves up a sandbox using kernel facilities with minimal permissions according to their task. IOW, bolting in the protections that Firejail is retrospectively attempting to do for the "bad" applications.

    FWIW, Windows developers have had a very technical ornery time achieving sandboxing, until W10, and only W10 development.

    Anyway, thanks again, very useful if I need to do some linux development.
     
  4. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    But how could any exploit code grap a file descriptor outside chroot if it is already inside it? I mean, it runs as a non-root, with all root capabilities dropped. It can't exec chroot(), setuid() or any other privileged function and doing chdir(..) does not get it to anywhere.

    So the only way I could think that bad code could worm itself out would be that the descriptor is already open before chrooting (either accidentally or intentionally) and then it would have to be a file descriptor to directory so that the bad guy could use fchdir().

    Example:
    Put int fd = open(".",O_RDONLY) just before chdir() and chroot() call, then after chroot() do fchdir(fd) followed with print_current_files()

    But right now, I can't think any reason why software would wan't to open directory file descriptor outside jail directory before chrooting. If we have a hypothetical network software X that is going to be chrooted, let's say, into /var/chroot/X it could have all it's configuration and log files inside that dir.

    Only file that would need to live outside of the X software would be a unix socket so that it could communicate with the rest of the system, created and opened just before chrooting.

    EDIT: Now that I think of it, there might be a way to prevent escaping even in the crazy situation that application would for some reason need open directory file descriptor .... have to start writing part 2 soon ...
     
    Last edited: Jan 15, 2018
  5. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    That is right. I wanted to write these things down before I forget them and at the same time help fellow developers and show that sandboxing is not hard.

    Your welcome :)
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.