• 1 Post
  • 12 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle
  • A process owned by any user will be able to exploit a userspace vulnerability, whatever this user is. Selinux, chroot, cgroups/containerization add a layer of protection to this, but any vulnerability that bypass these will be as exploitable from nobody as from any other local user. It will protect a user files from some access attempts but will fail to prevent any serious attack. And as usual when it comes to security, a false sense of security is worse than no security at all.

    Remember that some exploits exist that can climb outside of a full-blown virtual machine to the virtualisation host, finding a user escalation vulnerability is even more likely.

    The only real protection is an up-to-date system, sane user behavior and maybe a little bit of paranoia.












  • Unplug your mouse. Seriously. Do it. It might sound like the “kicking and screaming” method but you’ll learn to rely on your keyboard even for GUI tools and you’ll vastly improve how fast you navigate your computer. You should find yourself more and more in the terminal, obviously, but you may learn also some nice tricks with everything else.


  • Simple: because it goes against the KISS principle. The GNU tools that constitute the user interface to the system comes from a philosophy that started with Unix: simple tools, doing one thing well, communicating through “pipes” - i.e. the output of one tool is supposed to be used as the input of the next one.

    Such philosophy allows to assemble complex logic and workflows with a few commands, automating a lot of mundane tasks, but also allowing to work at a large scale the same way you would work on a few files or tasks.

    Graphical tools don’t have such advantages:

    • UI are rarely uniform in their presentation or logic, as there’s so much way to present options and choices;
    • Apple did something nice in the way of automating with AppleScript, but I’ve not encountered anywhere else. GUIs are rarely automatable, which means you’ll need some clicking and pushing buttons if a task has to be repeated - or the GUI has to be altered to be able to replay a set of commands for multiple items;
    • interconnecting different GUIs so that they can exchange data is just impossible. You usually end up with files in dedicated format, and the needs to massage data from one format to another to be able to chain tasks from different GUIs
    • more importantly, command line work with minimal bandwidth and tooling on the client side. Tmux, Mosh and similar tools allow to work with an intermittent connection, and have a very low impact on the managed system;
    • in some specific fields - notably embedded and industrial systems - you just can’t justify allocating resources just for a graphical environment. On these system, CLI is as powerfull as on a full fledged server, and don’t requires stealing precious resources from the main purpose of the system.

    Beware though: as time passes, Unix founding principles seems to get forgotten, and some CLI tools manifest a lack of user experience design, diverging from the usual philosophy and making the life of system administrators difficult. I’ve often observed this on tools coming from recent languages - python, go, rust - where the “interface” of the tools is closer to the language it’s written with than the CLI uniform interface.