Kushal Das

FOSS and life. Kushal Das talks here.

kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion

Securing verybad web application with only systemd

In my last blog post I talked about verybad web application. It has multiple major security holes, which allows anyone to do remote code execution or read/write files on a server. Look at the source code to see what all you can do.

I am running one instance in public http://verybad.kushaldas.in:8000/, and then I asked twitter to see if anyone can get access. Only difference is that this service has some of the latest security mitigation from systemd on a Fedora 35 box.

The service is up for a few days now, a few people tried for hours. One person managed to read the verybad.service file after a few hours of different tries. This allowed me to look into other available options from systemd. Rest of the major protections are coming from DynamicUser=yes configuration in systemd. This enables multiple other protections (which can not be turned off). Like:

  • SUID/SGID files can not be created or executed
  • Temporary filesystem is private to the service
  • The entire file system hierarchy is mounted read-only except a few places

systemd can also block exec mapping of shared libraries or executables. This way we can block any random command execution, but still allow the date command to execute.

Please have a look at the man page and learn about many options systemd now provides. I am finding this very useful as it takes such small amount of time to learn and use. The credit goes to Lennart and rest of the maintainers.

Oh, just in case you are wondering, for a real service you should enable this along with other existing mechanisms, like SELinux or AppArmor.

Introducing Very Bad Web Application

I am planning to add a few chapters on securing services in my Linux Command Line book. But, to make it practical & hands on, I needed one real application which the readers can deploy and secure. I needed something simple, say one single binary so that it becomes easier to convert it into a proper systemd service.

I decided to write one in Rust :) This also helps to showcase that one can write totally insecure code even in Rust (or any other language). Let me introduce Very Bad Web application. The README contains the build instructions. The index page shows the available API.

Issues in the service

The service has the following 3 major issues:

  • Directory traversal
  • Arbitrary file read
  • Remote code execution

I am currently updating the systemd (services) chapter in my book to show how to secure the service using only the features provided by the latest systemd. In future I will also have chapters on SELinux and AppArmor and learn how to secure the service using those two options.

If you think I should add some other nice security holes in this application, please feel free to suggest :)

eduGAIN Key Signing Ceremony

eduGAIN is a interfederation joining academic identity federations around the world, including over 4781 identify providers & 3519 service providers. The project was initiated by by the GÉANT research and education networking community in Europe.

On 8th of March, there was a key signing ceremony at Sunet office. This was my first chance to be able to attend one such ceremony in real life :)

hardware

The day before there was test run where I acted like a participant plugging in various cables/Yubikeys. A specific APU based airgapped box was used to generate the key, and it was talking over a serial port. Which in turn was split into two parts, one on a Mac where Björn Mattsson was doing the actual typing of the commands, and the other side was connected to a dot matrix printer. The printer printed every command & output of the ceremony. Apparently there were only 3 such paper rolls were available in whole of Stockholm.

Representants for the eduGAIN service flew in from different parts of EU as witness (there were many more online witnesses) and also participated in the ceremony. We also had many people present in the room (including Leif & I). Leif started describing the steps as they happened. At the end there were two copies of the keys & passphrase were made, and both the copies went to vaults of separate countries. The required material was also synced with the HSM cluster with the help of a super long cable :)

working on HSM

At the end of the ceremony the witnesses signed the printer pages containing the output.

signing the paper

This was a fun but important event for me to watch. The keys are generated for the next 20 years, so a lot of things will change in the world by the time we will have to do it again :) You can watch it all on Youtube.

Targeted WebID for privacy in Solid

In my last post I talked about the privacy issues from static public WebID in Solid. In this post I am trying to explain a way to preserve privacy, I will later submit a proposal (after figuring out how to) to change/update the original SPECs as required.

Targeted WebID for each unique client

Instead of returning the same unique WebID, the OP can return targeted WebID based on the client asking for the information. This will remain the same for every unique client and user, and can also be computed in future. This way every service accessing a Solid Pod server, will see a different unique URL for WebID, and those can not be used to co-relate the information.

We will have to update the OP (IDP) so that either it itself can calculate (or ask a different service) for the unique WebID every time.

Below I modified the official example flow to show (in step 19 and 20) how this can be achieved.

Sequence diagram

This brings in the question of how the user will learn/see all the available/used WebIDs for themselves.

That can be done by marking one client as the primary viewer/editor for the user, you can think it like a wallet. This solid application will be able to get the original unique WebID, and using that in the user's pod the wallet can find all the issued WebIDs. This goes into the implementation details of the pod server. Maybe all targeted WebIDs (& related pods) will be stored in a different namespace, maybe not.

I will write more in the next post.