Ah nice! Thanks for the suggestion. Yeah --preview is a great feature that is good to remember.

And true, it’s better to use find -executable than ls. Although in my case I would use -type f -o -type l since I want to include symlinks (often I will cd into my local bin folder and ln -s $(which ) to add it to my launcher). I’m using ls since I only put executables in there and using relative file paths so that it’s nicer to look at. But cd or sed would work as well

Yeah the xargs + i3-msg part is a bit clunky but I’m not sure what else to do, since the terminal window needs to close immediately, which prevents the application from running. I tried a few variations with nohup and launching in the background, but haven’t found another solution. But I’m sure there’s a way

I use fzf with a popup terminal:

# example for i3
bindsym $mod+Return exec --no-startup-id kitty -T _menu_ -e bash -c 'ls $HOME/.local/bin/ | fzf | xargs -r -I{} i3-msg -t command exec $HOME/.local/bin/{}'
for_window [title="_menu_"] floating enable
for_window [title="_menu_"] resize set 600 800

I like this approach because it’s simple and configurable. I prefer to see only the symlinks/scripts that I put in my local bin folder, but it can easily be extended to support .desktop files, multiple folders, filtering, etc.

👋 right on! I actually also have used containers as a key to my security layout before, but yeah you miss out on all the benefits of portage.

I was doing something crazy and actually running Gentoo inside each one! It was very difficult to stay up-to-date. But I basically had my host as barebones as possible and used LibVirt containers for everything, attempting to make a few templates that I could keep updated and base other VMs on. I was able to keep this up for about two years then I had to relax (was my main PC). But it was really secure, and it does work.

The benefit of encapsulation is that you have a lot of freedom inside each container, like install a different distro if you need to. Also as long as they are isolated you don’t need to worry as much about their individual security. But it’s still good to. I ran SELinux on the host and non-SELinux (but hardened) in the guests.

SELinux has a lot of advantages over users/groups, but I think the latter can be just as secure if you know what you’re doing. For example with SELinux you can prevent certain applications from accessing the network, or restrict access to certain ports, etc. It’s also useful for desktop environments where a lot of GUI apps run under one user- e.g. neither my main user nor any other program can access my keepassxc directory, only the keepassxc process (and root) can (even though the application is running under my main user). You can also restrict root quite a bit, especially if you compile in the option to prevent disabling SELinux at boot (I need to recompile my kernel to disable it).

But again while it is fun to learn, it is quite a pain and I’ve relaxed the setup on my new computer to use a different user for everything (including gui apps), which I think is secure enough for me. But this style relies on my ability to adhere to it, whereas with SELinux you can set it up to where you’re forced to

Like others have mentioned, SELinux could be a great addition. It can be a massive pain, but it’s really effective at locking things down (if configured properly).

However, the difficulty will depend on the distro. I use it with Gentoo, which has plenty of support/docs for it and provides policies for many packages. Although (when running strict policy types) I usually end up needing to adjust them or write my own.

Obviously Red Hat would be another good choice, but I haven’t tried it. Fedora also has good support, but I’ve only ever used the OOTB targeted policies.

That said, I’ve started relying on users/groups more often lately, since it really gets in the way of everything.

I alternate between helix and vim depending on the task, and their key bindings are kind of opposite from each other in a lot of ways. I’ve found that switching back and forth has kept me on my toes a bit and I don’t feel as locked in to one editor as I did with vim before trying helix.

So I’m now stuck with my customized neovim, devoid of any hope of abandoning this strange addiction.

I would also try getting used to the defaults or a minimal config, which is also a good way to feel at home in the editor regardless of the system

If you want to mess around with scripting instead of an editor I would recommend Awk- it works great for CSV files and is really powerful. Usually you can use -F, to separate using commas, but for full CSV support (with potential quoted commas) you need to use something like -vFPAT='[^,]*|"[^"]*"' (which isn’t POSIX compliant but works with gawk)

I’m not sure how to paste directly into a pane, but you can copy by opening up the scrollback in EDITOR from search mode using Ctrl+S e. This creates a file in /tmp so I try to make sure to clear it when I’m done.

I usually only copy and paste between editor windows using a script that mimics xclip (automatically used by helix), and if I need to paste a command I either edit my bash history or write a script.

Great list. Customizing the font is definitely a priority. I recommend one of the Terminus fonts. Also zellij multiplexer + helix editor is a great combo that works well in the tty.

One thing to add is that it took me a while to create a decent 16-color theme for helix and vim, and while they’re okay by default you can actually get a pretty nice looking IDE if you spend some time tinkering with the colors

I suppose the most tangible benefit I get out of it is embedding a custom initramfs into the kernel and using it as an EFI stub. And I usually disable module loading and compile in everything I need, which feels cleaner. Also I make sure to tune the settings for my CPU and GPU, enable various virtualization options, and force SELinux to always remain active, among other things.

mpd + ncmpcpp

Yes! Awk is great, I use it all the time for text processing problems that are beyond the scope of normal filters but aren’t worth writing a whole program for. It’s pretty versatile, and you can split expressions up and chain them together when they get too complicated. Try piping the output into sh sometime. It can be messy though and my awk programs tend to be write-only

Yeah for me it’s been great and I do essentially leave it plugged in the whole time I’m using my PC (attached to my keys). It does require a pin entered each boot, so leaving it in would still offer security. But as someone else mentioned getting kwallet PAM working would make things easier in any case

Lol. I press a button on the device (which I unlocked with a pin before boot), but it would be nice to have the DB unlock automatically

Personally, I’ve relied on an OnlyKey for a few years (with backups and an extra fallback device) and haven’t needed to type passwords since. This doesn’t help with the number of prompts, but it does make them easier to dismiss.

I do use autologin, but I don’t use a system wallet (only KeePassXC, which I do need to unlock manually). Autologin with system wallets can be tricky, but I’ve had some luck setting it up in the past. You might want to check out this wiki for PAM configuration.

I usually use Awk to do the heavy lifting within my Bash scripts (e.g. arg parsing, filtering, stream transformation), or I’ll embed a Node.JS script for anything more advanced. In some cases, I’ll use eval to process generated bash syntax, or I’ll pipe into sh (which can be a good way to set up multiprocessing). I’ve also wanted to try zx, but I generally just stick to inlining since it saves a dependency.

I started by writing small scripts to automate things, but really got into it after learning how fun it can be to make the computer do stuff. I also see it as a kind of creative outlet, but in general I just want to learn how to fix anything in software if I’m not satisfied with how it works.

If you’re willing to spend the time to learn how to write custom policies, SELinux can be used for this, to some extent. It’s highly customizable and can sandbox your apps, but the process of doing so is quite complicated. I wrote a small guide on custom policy management on Gentoo in another comment if you’re interested.

There’s also apparently a “sandbox” feature, but I don’t know much about it. I just write my own policies and make them as strict as possible.

As an example, my web browser can’t access my home directory or anything except its own directories, and nobody (including my own user), except root and a few select processes (gpg, gpg-agent, git, pass) can access my gnupg directory.

This only covers security/permissions, and doesn’t include many of the other benefits of containerization or isolation. You could also try KVM with libvirt and Gentoo VMs; that works pretty well (despite update times) and I did that for a while with some success.

np! Hope it helps; it’s a big pain but I do think it’s pretty secure if configured correctly

I’m happy with it so far! No swipe typing, and it’s pretty difficult to land on the right key, but I’ve found that I’m getting better at using it with time, especially after customizing it to my liking

Awesome! Here are a few things that come to mind:

Make sure you have some aliases/functions for common operations:

• audit2allow -a to view audit violations (or -d for dmesg audits)
  • also -r to add a requires statement for module construction
• restorecon -Rv to recursively apply file contexts from policy (or -FRv to also apply user context)
• rm -f /var/log/audit/audit.log.*; >/var/log/audit/audit.log to clear audit logs
  • note: sometimes lots of logfiles (audit.log.1, etc.) collect, slowing down audit2allow
• chown -R user:user PATH; chcon -R -u user_u PATH to recursively change labels to user
  • could be generalized for arbitrary Linux/SELinux users
• semanage fcontext -a -t TYPE PATH -s $SEUSER to add a custom file context to the policy
  • e.g. semanage fcontext -a -t "user_secrets_t" "/home/[^/]+/.secrets(/.*)?" -s user_u
  • I’ve had better luck with this approach than the standard method of creating a .fc file, but in any case a custom policy is needed to create custom types
• semanage fcontext -d PATH to remove a custom file context
• semanage fcontext -lC to list custom file contexts
• semodule -DB to rebuild policy with all dontaudit rules disabled
  • often, something will not work, but audit2allow doesn’t show anything
• semodule -B to rebuild policy (with dontaudit rules)
• semodule -i MODULE.pp to install a module
• semodule -r MODULE to remove a module

Also a few scripts for policy creation and management are essential. There are two basic approaches to policy creation: modules and policy modules.

Modules: can be used to modify AVC rules and are pretty simple

# a violation has occurred that you want to allow or dontaudit
echo "module my_allow 1.0;" > my_allow.te
audit2allow -ar >> my_allow.te

# verify that my_allow.te has what you expect
cat my_allow.te

# build and install the module (replace mcs with whatever policy you are using)
make -f /usr/share/selinux/mcs/include/Makefile my_allow.pp
semodule -i my_allow.pp

# clear audit logs
rm -f /var/log/audit/audit.log.*; >/var/log/audit/audit.log

Policy modules: can do anything, but are complicated, and the tools for creating them are mostly based on Red Hat.

Creating a new type:

# generate foo.fc, foo.if, and foo.te
sepolicy generate --newtype -t foo_var_lib_t -n foo

# note: see sepolicy-generate(8); sepolicy generate only supports the following
#       type suffixes, but its output files can be adapted to your use case
# _tmp_t
# _unit_file_t
# _var_cache_t
# _var_lib_t
# _var_log_t
# _var_run_t
# _var_spool_t
# _port_t

# modify the .fc file with the desired file contexts, for example (with s0 for mcs)
# /path/to/context/target	--	gen_context(system_u:object_r:type_t,s0)
#
# note: the "--" matches regular files, -d for directories, -c for character
#       devices, -l for symbolic links, -b for block devices, or can be omitted
#       to match anything. also, as mentioned before, I often have better luck
#       with `semanage fcontext`, especially for user directories
vi foo.fc

# build and install the policy module
make -f /usr/share/selinux/mcs/include/Makefile foo.pp
semodule -i foo.pp

# use restorecon to adjust the file contexts of any paths you have 

# by default, all operations involving this type will be denied
# (and are sometimes not audited)
semodule -DB # --disable_dontaudit
# ... use the type, collect violations ...
audit2allow -ar >> foo.te
# if dontaudit is disabled, you'll likely have a lot things to remove from here
vi foo.te

# ... repeat until rules regarding type are fully defined

Creating a new application type:

# sepolicy-generate is made for Red Hat,
# but you can use --application to get started

# creates a bunch of files that define bar_t and bar_exec_t
sepolicy generate --application -n bar [-u USER] CMD

# remove the line making the app permissive (up to you, but
# I prefer using audit violations to define the permissions)
perl -i -00 -pe 's/^permissive bar_t;\n\n//g' bar.te

# ensure that the file bar_exec_t file context points to the right bin:
vi bar.fc

# build and install the policy module
make -f /usr/share/selinux/mcs/include/Makefile bar.pp
semodule -i bar.pp

# ... use the application, update AVC rules, repeat ...

If your target application is interpreted, you’ll need to write a custom C program that launches the interpreter in a specific context, then write your policy around that application. For example, you should execv something like this: /usr/bin/runcon -u user_u -t my_script_t /bin/bash PROG.