linux

Enforcing Complex Passwords In Manjaro

Leave a comment

Manjaro has a weird password-quality setup. The password-quality functionality is provided by the libpwquality package, which provides a PAM plugin named pwquality.so and configuration at /etc/security/pwquality.conf . However, once installed it seems to still not be referenced by the PAM configuration and will not be applied to password changes.

Before making changes, open a root prompt. You will make your changes here and have a place to restore your configuration from if you break anything. Make a backup of /etc/pam.d/system-auth .

Make sure you have the libpwquality package installed.

Open /etc/pam.d/system-auth . There are PAM configurations that deal with authenticating the user and PAM configurations that deal with updating passwords. Look for the password-setting configuration block; those lines will have “password” as the module-type (first column):

-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow
password   optional                    pam_permit.so

Insert the line for pam_pwquality.so above (always above) pam_unix.so, and update the configuration for pam_unix.so to:

password requisite pam_pwquality.so retry=3
password required pam_unix.so try_first_pass nullok shadow use_authtok

The change will apply immediately, though you probably will not see a difference with the default password-quality configuration settings.

Make your desired changes to /etc/security/pwquality.conf . We recommend the following settings:

minlen = 10
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1

Open the shell for a nonprivileged account that you would like to use to test password changes and proceed to test the password-quality options that you enabled in order to ensure they work as expected. If you made a mistake, fix them in the root console that you should still have open.

Important note: Unless you have enabled “enforce_for_root” in the password-quality or PAM configuration, you will only see advisory warnings for nonconformant passwords when running as root. You will still be able to set any password you’d like.

Register New Executable Formats In The Linux Kernel

If the kernel identifies that a file you’re trying to execute has a known sequence of magic bytes, it will happily execute it. However, you might want to run certain formats without needing to pass them to another tool. In as much as these are usually binary tools, you can prepend a magic-bytes preamble (or use an existing sequence, if your binary format already declares one) and then associate that with a certain loader in the running kernel using binfmt_misc. Access is usually via procfs (currently /proc/sys/fs/binfmt_misc/register). Cross-execution with a virtualized process is a common use-case for this.

Note that this doesn’t really apply to text files (it’s all data) because you’d need to inject gibberish at the top of your file to use this functionality when using a shebang (which is meant for this case) should work just fine.

This is a walkthrough of how to do this for compiled Python or LUA source-code: https://twdev.blog/2024/01/docker_multi_platform

Since both of the example compilation formats include magic bytes, you can just write a tool to acquire those from libraries (at least with Python) and call binfmt_misc in one step.

You can also write configs to be automatically loaded at boot. There appears to be no way to list registered formats, with the only recourse being to sift the config paths (probably empty by default) or to check your kernel config to see which supported formats were included in that build.

Use ADB to Connect to Your Android Device From a Docker Container

2 Comments

You may have a use-case where you want to write software to manipulate an Android device using a system or set of tools that are not natively available from your current system. However, you might be able to expose this as a Docker image. For example, your device is (or will be) connected to a Windows machine and you really want to or need to use Linux tools.

No problem. ADB implicitly uses a client-server model: The ADB tool (on your system) connects to the ADB server (runs in the background on your system) which interacts with the ADB daemon (runs on your device). This means that we can forward requests from ADB on the command-line in the guest container in Docker to the ADB server on the host system.

The ADB client and server have to be at the same version, or the client will indiscriminately kill/restart your ADB server. So, as I am currently running Ubuntu 14.04 on my host system, I will do the same in Docker.

First, I will make sure the ADB server is running on my host system. Most of the subcommands that will automatically start the local server, but I will start it directly:

$ adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

Now, I will start a container in Docker with Ubuntu 14.04 and automatically install ADB before dropping to a prompt. Note that we are passing “–network=host” in order to share the host’s network identity:

$ docker run -i -t --network=host ubuntu:14.04 /bin/bash -c "sudo apt-get update && sudo apt-get install -y android-tools-adb && /bin/bash"

Eventually, you will end-up at the prompt. Just do something simple like enumerating the devices:

root@mlll2664:/# adb devices
List of devices attached 
05157df572841820 device

The “mlll2664” hostname, represented in the prompt in the Docker container, is, actually, the same hostname as my host system.

So, there you go. Not too painful.