I have a website, where users are available to upload small applications which runs 24/7 on my server.

So if the user upload an application, some folders will be created:


(if the user folder already exists, the /{USER_ID}/ folder will not be created again)

Inside this directory, the application files will be stored. For each application the user create, a bash file will be created inside the /{APP_ID}/ folder which contains the start command for the application.

For example if the user upload a .NET Core application, a bash file will be created which contains nohup dotnet app.dll ....

My question is, how I can secure my server the best way to limit the user's applications rights.

If the user created the application he can click a start button on the website which will run the start.sh bash file.

What is, if the application the user uploaded change the content of the bash file which can damage the server?

I want to prevent that by making the bash file non-editable/movable/deletable etc.

But I guess u can just do more bad stuff to damage the server.

So how I can prevent the user to only have rights to do stuff inside its folder own folder (/{USER_ID}/) [only userid because i dont care if the user damage his own applications].

My idea is that if the directory (/{USER_ID}/) will be created first, php will create a user on my server with only rights inside the /{USER_ID}/ folder.

Will this be secure enough ?

My os is Ubuntu 16.04.

1 Answer 1


Just isolating filesystem access is not enough by itself to protect the rest of the system, and it's also notoriously hard to do right (chroot can be pretty easily escaped, SELinux is a pain in the arse to set up, etc). Among other potential means of attack you have:

  • IPC objects (semaphores, POSIX message queues, signals, etc). There's no easy way to limit which process can manipulate which IPC objects, but globally blocking them will actually break many legitimate programs.
  • Network access. This is easy to block, but obviously is not covered by just restricting filesystem access.
  • Certain types of resource limitations are actually pretty easy to side-step as a regular user (CPU affinity for example).
  • Without some effort on your part, your new users will have pretty easy access to certain types of hardware on the system.
  • Even aside from the above, there are a lot of system calls that should never be called by regular user code but can be (vm86 and iopl are probably two of the best examples).

Ideally, assuming you don't want to deal with complicated manual setup, look into a tool like firejail. While it's not designed for this exact use case, it should be pretty trivial to adapt to it, and it's dead simple to configure compared to most sandbox software. With a sane configuration, firejail can:

  • Securely restrict filesystem access in a way that's easy to configure.
  • Similarly protect IPC objects.
  • Restrict usage of capabilities.
  • Limit network access, possibly using a completely different network configuration from the host system.
  • Force specific CPU affinity.
  • Spoof a variety of common identifying information for the system (hostname, machine ID, data reported by uname, etc).
  • Disallow execution of memory that is or was writable (only on some architectures).
  • Disable access to a wide variety of hardware that may otherwise be accessible.
  • Explicitly prevent execution of code in certain directories.
  • Make certain directories ephemeral (they will lose state when the sandbox closes, great to ensure that temporary files get cleaned up).
  • Set and enforce various resource usage limits for the processes inside the sandbox.
  • Explicitly block specific system calls (the default profile with this enabled will block most of the ones that aren't needed by most applications and are a potential security risk).
  • So firejail is similar to docker ? The idea I have right now to create a docker image for each user and inside this image the application will run. May this be a secure way ?
    – xKushGene
    Commented Oct 17, 2018 at 18:39
  • If done right, Docker would work. However, it also comes with a lot of infrastructure you arguably don't need, and makes certain assumptions about how you will use it that may make this difficult. That's the biggest difference between Firejail and Docker actually, Docker pretty implicitly assumes you are planning on running a microservice cluster on it (which it sounds like you specifically aren't), while Firejail just assumes you want to sandbox things, so Firejal doesn't bundle in all the maintenance complications that come with Docker. Commented Oct 17, 2018 at 18:44
  • im trying docker at the moment and its a bit difficult. So firejail would be easier to create a container for each application ?
    – xKushGene
    Commented Oct 17, 2018 at 18:55
  • Probably. Firejail was designed originally to be easy for desktop users to isolate individual applications (for example, running a web browser in a sandboxed environment). Because of this, it's reasonably easy to create a single container with it. The tricky part in your case is likely to be figuring out what security restrictions to impose. However, the documentation for Firejail itself is reasonably good, and the community is helpful, so it shouldn't be too hard. Commented Oct 17, 2018 at 19:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .