Is security-misc suitable for hardening bridges and relays?

I run a few bridges and relays (they are VPS with Debian). I was wondering whether installing the security-misc package could be a good idea in order to harden their configuration. Suggestions? Hints? Previous experiences? Am I going to break my beloved relays?

Thanks and sorry for the kind of generic question.

This post talks about the status:


It shouldn’t™ cause any grave issues unless you do the extra stuff documented on Whonix-Workstation Security Hardening - Whonix

Although, we can’t be sure as we don’t have that much testing as described above.

Hello both and thanks for your kind replies. Apologies for the late answer but I have been kind of busy today.

Well, I tried to install security-misc on a private relay I am running for testing purposes. After the reboot when I tried to become root (using ‘su’) with my normal user. Unfortunately the system said “User not authorized” (or something like that, I do not remember exactly). Not sure why this happened.

Also, since my normal user was not in the sudoers list I was not able to become root AT ALL :rofl: :rofl:

Not a great problem, I just reinstalled from scratch the system. For now, I think that I will just copy and paste the kernel parameters in /etc/sysctl.d, testing them line by line. Not very comfortable, but it is better than reinstall my system one more time.

Thanks for your answers.

1 Like

security-misc restricts su only to users within the sudo group. You need to add your user to the sudo group.

security-misc does much more than change some sysctl settings.

1 Like

Since all my systems have some user with sudo this use case was not considered. Indeed. Installation currently might brick a system until recovered using:

  • boot menu into recovery mode - Recovery - Kicksecure
  • using a live dvd to boot and fix
  • on a server perhaps using management console (if that somehow becomes root)

What could we do to solve the bricking risk? A preinst script that checks if at least one user is in group sudo and abort installation if that is not the case? Not sure that can be implemented but guess yes.


Maybe just put a warning in the readme.

Hello both,
thanks again for your answers and suggestions. I think security-misc on a relay worth another try. As madaidan correctly pointed out this package is not just kernel settings. So, I added my user to the sudoers group and everything seems to be alright now.

I am testing the relay and I am not experiencing any particular issue in term of latency, but yeah, I have just started. Is there any test you suggest to run (a part use on a daily basis)?

1 Like

I have been testing security-misc for more than a week on public/private bridges and a couple of onions I run. I have not experienced any problem at all. No drops in number of daily users, no drops in advertised bandwidth, not even a connection slower than usual. Nothing is changed (which generally is good).

Obviously, I do not think that my daily use can be considered as valuable technical data in order to assess whether security-misc is suitable or not for bridge/relays/onions. Again, if there are tests to run or parameters to monitor, I will be glad to look after them.

It could be good to keep testing security-misc in this perspective. As everybody know, the Tor network has a huge problem in term of OS diversity. Security-misc does not solve it, but could be useful in order to provide some security-by-default to the thousands of relay operators running Debian in order to contribute to the network.

Or not?


I locked myself out of a VM again because of security-misc… again (I am not saying that security-misc is the culprit, more likely it is my lack of technical expertise). What did I do?

a) I removed security-misc from a Debian Based VM.
b) I log out the VM.
c) I log in the VM.
d) If I try to sudo su this is the output:

/usr/lib/security-misc/pam-abort-on-locked-password failed: exit code 2 sudo: PAM authentication error: System error

I can’t become root anymore. No problem, it was just a small bridge and I can reinstall and reconfigure it easily. However I am wondering… Is this normal? Is it an unintended effect or not?

Thanks in advance.

P.s: the normal user is in the sudoers group.


For sure unintended. A bug. Removal isn’t well tested. For removal, try as root.

pam-auth-update --package

The package should do that automatically, but I haven’t figured out yet why it doesn’t.

security-misc/security-misc.prerm at master · Kicksecure/security-misc · GitHub

1 Like

Well, unfortunately I can’t run this command since I can’t become root anymore (I’ve tried with su, sudo su, su root but the output is always the one mentioned above).

Nevermind, I will be glad to test the new release of security-misc when a fix will be deployed :slight_smile:

1 Like

You can try using one of the methods here Recovery - Kicksecure


Hopefully fixed.

Can take a while until available form all repositories as usual as per Bug Reports, Software Development and Feature Requests


I managed to rescue the system through the control panel of my VPS provider. I will be happy to test the fix once it is released.

When it is ready, it is ready :slight_smile:

1 Like

Well, it’s ready for installation. No changes related to that. The package removal bug will be fixed later whenever the package migrates. Don’t hold your breath for that.

For removal, make sure to have a second root shell open.

sudo pam-auth-update --package

Then keep that shell open and try opening another root shell. If that still works, you’re golden. You could try in a VM first (take snapshot before trying) if removal is an important feature to test for you.

:slight_smile: As I said, when it is ready, it is ready.

Yep, already done these tests yesterday. Everything seems to work fine.

One more thing. After more than one month of testing with security-misc on several public bridges everything seems to be fine.

And… another thing. This is my shout out to Whonix. I really like this project for many reasons. This environment is a forge of experimentations - corridor, kloak, lkrg, tirdad, security-misc, kernel hardening and many more stuffs - where one can play, learn and making mistakes without hurting himself/herself/themselves and/or the people around him/her/them. In my own and subjective experience, this is true for the technical layer upon which Whonix is built (Debian = easy, Qubes = many templates cloned, many mistakes done, never experienced a serious problem, Tor = ephemeral identites) but also for the “human” layer as well. Indeed, I find this environment accessible and friendly also for a not-really-techie person (as I clearly am). I won’t even mention the documentation: not only endless and up to date, but also capable of fostering a reflection in the final user about the crisscrossing relations between politics and technique (again, this is my own subjective experience).

And after all this blablabla I will be happy to make a donation.