1. 21
  1. 5

    On my HardenedBSD IRC box, I’ve hardened my IRC setup by:

    1. Compiling irssi with full RELRO and SafeStack
    2. Deploying irssi within a jail (in linux terms: a restricted container)
    3. Ensure that HardenedBSD’s PaX NOEXEC and PaX ASLR implementations cannot be disabled for the jail
    4. In my firewall, enforced that the IRC system can connect to certain IRC networks and nothing more
    5. In my firewall, ensured all DNS traffic goes through my hardened DNS server that logs all queries

    There’s probably more I’m forgetting.

    1. 7

      I love systemd services and templates and the features it has to restart things, but I think this is a pretty absurd thing to say:

      and run it as a systemd service, because how else are you going to start this thing anyways, cron?

      Does anyone seriously think that Linux didn’t properly support services before systemd? It’s not like /sbin/init was symlinked to bash

      1. 5

        i’m dealing with this right now on Alpine Linux, which doesn’t use systemd. other than xdg autostart, there are no user services. the autostart thing is very very limited compared to systemd user services..

        1. 3

          the point i was making here is that there’s some sort of a controversy around adoption of systemd across major linux distribution in general, and in Debian in particular. It was a tongue-in-cheeck comment about how i am making a stand and declaring systemd as a standard, even though there is an ongoing controversy, but i’m too tired of that debate to engage into it in that specific post.

          I find the fact that you not only bit on the bait but also that your comment here is the most highly rated kind of strange, to be honest. You’d think comments regarding the actual setup would be more interesting than a single line commenting on that controversy.

          Or maybe people assumed I truly didn’t know about alternatives to systemd, in which case I apologize: it is obvious, to me, that there are multiple ways of starting processes outside of systemd (cron being the actual, truly most common occurence i find in the wild, because it allows regular users to inject themselves in the boot process without root).

          i hope that clarifies things…

        2. 3

          Didn’t know about dtach; having fewer features makes it rather suited to this use case. Along vaguely similar lines, there’s also reptyr which uses ptrace to change the tty of an existing process.

          At some point, I tried to configure things so irssi would use my VPN for connections - /whois provides too much information - but Freenode appeared to reject the connection.

          1. 1

            I feel like a hardened container with seccomp would go a long way towards achieving the same goal without having to crack into the systemd arcana.

            1. 4

              So instead of simple systemd unit you would bring all complexity of containers as seccomp? And what kind of “arcana” you are even talking about?

              1. 1

                In my opinion, there are more resources available for understanding how to do this with a container (both the dtach part and the syscall sandboxing), than there are with dtach and systemd units. If you sat me down and asked me to do this, it would be much easier to find the resources I need for containers rather than trying to set up a systemd unit file.

                1. 7

                  One reason there aren’t a plethora of different resources covering this in the systemd case is because their man pages have it covered so thoroughly there’s no need for some third party take.

                  1. 3

                    Well, you can look through blog posts utilising enormous amount of Google-fu and arcane ability of “what did the author meant by that” or you can just use man systemd.exec and read everything even offline.

                    There are bad things in systemd, but for sure documentation isn’t one.

                    Additionally you do not need to worry about:

                    • running reaper within container to not be overcrowded with zombies
                    • remembering to update all containers in case of security update
                    • worry about proper configuration of runtime, like creating users within containers
                    • running daemon with root (assuming Docker there, and while not required to do so anymore, this is still t most popular approach)

                    And so on, and so on.

                    With systemd all you need is simple text file with no more than 50 lines and additionally you can have more goodies like for example lazy activation of service only when needed instead of running all the time.

                2. 3

                  You don’t need containers to do that. You can simply add them to the systemd unit.

                  1. 1

                    See point I made to @hauleth

                    1. 1

                      See point I made to @hauleth

                    2. 2

                      if you look at the actual .service file i deploy, you’ll find that I did try to enable some seccomp stuff, but it was pretty hard to achieve. would love to see your (working) seccomp configuration for irssi/dtach!

                    3. 1

                      Oh a puppet module in the wild. I mostly see ansible stuff.

                      1. 2

                        you mean shell scripts wrapped in jinja templates wrapped in python code? yeah, i heard of those. ;)

                        1. 1

                          tbh I haven’t found an ansible/saltstack/pupped system that is actually good and not feeling like more overhead than just manually doing all of this, when you don’t have to provision multiple machines with the same service and just want to streamline the question of “how was this system set up and how can I rebuild this VM” - inclusive the data of backups (and let’s not talk about systems that want to be configured by their web UI)

                      2. 1

                        Never knew about dtach, it seems i might need to try it, as that’s all I ever really use screen or tmux for. Simplifying it to just that sounds great.

                        Also the systemd stuff is neat, I might use it for some other things that I run in Linux land, and comboing it with dtach is a nice idea.