Using custom-styles.scss

Minima v3 provides a built-in method for adding your own custom CSS. All you have to do is create a file at _sass/minima/custom-styles.scss, relative to the root of your Git repository. Any CSS you add to this file will augment – or override – Minima’s default styles.

If you want to add Sass variables and mixins, there’s a file for that, too: _sass/minima/custom-variables.scss.

Here’s an excerpt from the “customizing templates” section of Minima’s README that explains exactly how these override files are meant to be used:

To have your CSS overrides [remain] in sync with upstream changes released in future versions, you can collect all your overrides for the Sass variables and mixins inside a sass file placed at _sass/minima/custom-variables.scss and all other overrides inside a sass file placed at path _sass/minima/custom-styles.scss.

Bonus Section: Minima v2 Versus v3

At the time of this writing, GitHub Pages still uses Minima v2 by default. This is important, since Minima v3 (which hasn’t yet been officially released) includes several non-backwards-compatible changes, including what’s discussed in this post. Adding custom CSS to Minima v2 is totally different.

If you want to use Minima v3 on GitHub Pages – like I’ve done on this site – you have to load the theme in via the jekyll-remote-theme plugin. This can be accomplished with a single line in your site’s _config.yml file:

remote_theme: "jekyll/minima"

Ubuntu’s PAM Config Framework

The pam-auth-update script and its associated PAMConfigFrameworkSpec were originally written by Steve Langasek¹ and were added to Debian and its derivatives in 2008².

The spec page linked above is the best online resource for understanding this framework that I am aware of, but I’ll provide a brief summary here:

1. Packages – or enterprising administrators – can install custom PAM profiles into /usr/share/pam-configs/. This allows packages to specify how their PAM modules should be integrated into the system PAM stack.
2. Once installed, these custom PAM profiles can be enabled or disabled with the pam-auth-update script.
3. When PAM profiles are enabled or disabled, pam-auth-update modifies the system-wide PAM configuration files at /etc/pam.d/common-* accordingly.
4. The script can be run interactively by an administrator or non-interactively by configuration management tools or package maintainer scripts.

PAM Basics

First, let’s review some PAM basics. As described in the man page for pam.d, there are four types of PAM modules:

1. account

   this module type performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user – ‘root’ login only on the console.

2. auth

   this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership or other privileges through its credential granting properties.

3. password

   this module type is required for updating the authentication token associated with the user. Typically, there is one module for each ‘challenge/response’ based authentication (auth) type.

4. session

   this module type is associated with doing things that need to be done for the user before/after they can be given service. Such things include the logging of information concerning the opening/closing of some data exchange with a user, mounting directories, etc.

The PAM module for Duo Unix falls into the auth management group, so, for the purposes of this post, that’s the only relevant module type.

Ubuntu’s System-Wide PAM Configuration

Ubuntu provides five system-wide PAM configuration files in /etc/pam.d that correspond to these four types of PAM modules and are designed to be included by services that rely on PAM, such as sshd and sudo:

1. /etc/pam.d/common-account: Authorization settings common to all services.
2. /etc/pam.d/common-auth: Authentication settings common to all services.
3. /etc/pam.d/common-password: Password-related modules common to all services.
4. /etc/pam.d/common-session: Session-related modules common to all services.
5. /etc/pam.d/common-session-noninteractive: Session-related modules common to all non-interactive services.

These are the files that pam-auth-update manages. For context, our PAM profile for Duo Unix will only affect /etc/pam.d/common-auth.

With all this in mind, we can move on to writing the profile.

Writing the PAM Profile

Here is the PAM profile I’ve come up with for Duo Unix:

Name: Duo two-factor authentication
Default: no
Priority: 128
Auth-Type: Additional
Auth:
	required	/usr/lib64/security/pam_duo.so

The table below describes what each individual field does and explains why I chose the options I did:

Finally, the profile must be installed at /usr/share/pam-configs/duo-unix in order for it to be readable by pam-auth-update. I’ve chosen to use duo-unix as the filename for the profile since convention dictates it should match the related package or module name.

Enabling the PAM Profile

Once the profile has been installed, it can be activated with pam-auth-update. There are three ways to do this:

1. Interactively, as an administrator:

   Run pam-auth-update as root, check the box next to “Duo two-factor authentication”, and select “OK”.

2. Non-interactively, as a package maintainer script:

    pam-auth-update --enable duo-unix --package
   

3. Non-interactively, as an administrator or as a configuration management tool:

    pam-auth-update --enable duo-unix --force
   

Note: The third option will overwrite your current system-wide PAM configuration without prompting, which should be safe unless you’ve manually edited the aforementioned system-wide PAM configuration files in /etc/pam.d.

Example Puppet Code

Here’s a minimal working example for how to do all of this in a Puppet module:

file { '/usr/share/pam-configs/duo-unix':
  ensure  => file,
  owner   => 'root',
  group   => 'root',
  mode    => '0644',
  content => file("${module_name}/pam-config-duo-unix"),
} ~>
exec { "${module_name}_enable_pam_module":
  command => 'pam-auth-update --enable duo-unix --force',
  unless  => 'grep -q pam_duo\.so /etc/pam.d/common-auth',
  path    => [ '/sbin', '/usr/sbin', '/bin', '/usr/bin' ],
}

Closing Thoughts

In doing things this way, I’m breaking with Duo’s official recommendation for Ubuntu systems, which is to modify the default call to pam_unix.so in /etc/pam.d/common-auth and insert a call to pam_duo.so directly afterwards. However, what I propose here should be both functionally identical and safer. Also, if you’re using pam_sss.so in conjunction with (or instead of) pam_unix.so to enable authentication via SSSD, Duo’s recommendation won’t work anyway.

It’s also worth mentioning that enabling Duo Unix in the manner described above should enable Duo for any authentication flow that relies on PAM’s common-auth stack, including sudo. One notable exception to this rule is key-based authentication in SSH, which evidently bypasses the PAM auth stack entirely. Enabling Duo for SSH key authentication is outside the scope of this post⁴.

Also, the legacy login_duo approach for enabling Duo Unix⁵ is outside the scope of this post. It relies on OpenSSH’s ForceCommand directive and is nowhere near as robust as the PAM module.

PowerShell Method (Modern)

Since the WMIC utility is now deprecated, the modern way to perform this query is with the Get-CimInstance cmdlet in PowerShell:

Get-CimInstance -ClassName Win32_BIOS | Select-Object SerialNumber

That’s the right way to do it if you’re running this query in a script. However, if you’re doing this by hand, that’s a lot to remember and type, so I’d recommend using an abbreviated version instead:

(gcim Win32_BIOS).SerialNumber

You can also use the following version, which returns more than just the serial number but is even easier to remember:

gcim win32_bios

Note: Some sources suggest using the Get-WmiObject cmdlet, but that’s deprecated too.

WMIC Method (Legacy)

This is hardcoded into my brain from years of manual Windows deployments, so even though it no longer works on recent Windows installations, I’ll include it here for posterity:

wmic bios get serialnumber

Remember: wmic.exe is deprecated and will eventually stop working.

However: I don’t need Netplan, because I can configure systemd-networkd directly with Puppet (or possibly OpenVox in the future). Netplan can play nice in this scenario, since it writes to /run/systemd/network/ instead of /etc/systemd/network/, but I don’t want it fighting with my configuration management tools over something as critical as network configuration.

Problem: Metapackages

So, why not just purge Netplan with apt purge netplan.io && apt autoremove? Well, because doing so breaks the ubuntu-minimal metapackage:

This package [ubuntu-minimal] depends on all of the packages in the Ubuntu minimal system … It is also used to help ensure proper upgrades, so it is recommended that it not be removed.

Ubuntu certainly won’t stop you from doing this, but breaking metapackages is a great way to run into weird issues down the road.

Solution: Purge Config & Reapply

Here’s my compromise: Leave Netplan installed, but purge its config files. Fortunately, this is pretty simple. According to the FAQ, Netplan config files may exist in three different directories, in order of precedence:

1. /run/netplan/
2. /etc/netplan/
3. /lib/netplan/

The key is to run netplan apply after removing the relevant files from those directories. This removes Netplan’s generated configuration from the network stack.

Note: This is a disruptive action, so make sure you have an alternate network configuration ready to take over after Netplan lets go of the reins!

All together, the whole process might look something like this:

$ sudo rm -f /run/netplan/*.yaml /etc/netplan/*.yaml /lib/netplan/*.yaml && sudo netplan apply

Example Puppet Code

If you’re a Puppet aficionado, here’s one way to do this from inside a module:

file { '/etc/netplan/':
  ensure  => directory,
  owner   => 'root',
  group   => 'root',
  mode    => '0755',
  purge   => true,
  recurse => true,
  force   => true,
} ~>
exec { "${module_name}_regenerate_config":
  command     => 'netplan apply',
  path        => [ '/sbin', '/usr/sbin', '/bin', '/usr/bin' ],
  refreshonly => true,
}

Recently, I’ve been compelled to start again. Maybe it’s the result of reading one too many AI-generated Medium articles, or maybe it’s a reaction to my growing sense of dismay about the perceived death of the Web I grew up with, a place where people wrote their own content and Google Search actually worked. Or, maybe I just feel indebted to people like Chris Siebenmann, Joel Spolsky, and all others whose content has helped me over the years.

In any case, here we are again, this time on GitHub Pages. Let’s see what happens next.

No pattern file found in ~/ado/plus/p/

This error indicates that your installation of the dm0082 package is missing several important ancillary files. We specifically encountered this error on a Linux system, but you’ll likely see a similar message on Windows or macOS.

Solution: Install the Missing Ancillary Files

The root cause of this error is that the ancillary files for dm0082 are not automatically placed in the correct location when they are installed. Instead, they are copied to your current working directory. The following pattern files will need to be moved from your current working directory to the folder referenced in the error message above:

P10_namecomp_patterns.csv
P21_spchar_namespecialcases.csv
P22_spchar_remove.csv
P23_spchar_rplcwithspace.csv
P30_std_entity.csv
P40_std_commonwrd_name.csv
P50_std_commonwrd_all.csv
P60_std_numbers.csv
P70_std_nesw.csv
P81_std_smallwords_all.csv
P82_std_smallwords_address.csv
P90_entity_patterns.csv
P110_std_streettypes.csv
P120_pobox_patterns.csv
P131_std_secondaryadd.csv
P132_secondaryadd_patterns.csv

On Linux, the proper destination for these files will likely be ~/ado/plus/p/. If you are on Windows, it will likely be c:\ado\plus\p\ instead.

Note: Make sure that the name of each pattern file starts with a capital “P” rather than a lowercase “p”. The filenames may change to all lowercase when the ancillary files are downloaded. If that happens to you and you’re running Linux, you can use the rename command as described in this Ask Ubuntu post to quickly fix all the filenames at once.

Bonus Section: Finding Stata’s PLUS Directory

If you want to confirm whether the folder referenced in the error message is correct, you can find your local Stata PLUS directory by running the sysdir command:

. sysdir
   STATA: /usr/local/stata17/
    BASE: /usr/local/stata17/ado/base/
    SITE: /usr/local/ado/
    PLUS: ~/ado/plus/
PERSONAL: ~/ado/personal/
OLDPLACE: ~/ado/

More info about the PLUS directory from the Stata FAQ:

PLUS is where Stata installs ado-files from the SJ and STB and ado-files that you have downloaded from the Internet through the help system or with the net command.

References:

• Fuzzy match in Stata - Kai Chen

Examples of Common Issues

Let’s start by looking at a few issues I’ve had in the past that turned out to be caused by SELinux:

1. A user could no longer log in with an SSH key after their home directory was restored from a backup. Their authorized_keys file was configured correctly but was being ignored by SSH.
2. A service wouldn’t start after replacing its config file with a modified version that had been uploaded via SFTP. The service complained about the config file being inaccessible even though its permissions were set correctly.
3. Postfix couldn’t communicate with OpenDKIM when the latter was set to use a UNIX socket instead of a TCP/IP socket. The Postfix user was in the correct security group and the socket was configured correctly.

Without a general understanding of how SELinux works, you might guess that the issues above were caused by bad file permissions. That’s why it’s important to understand SELinux and to identify it as a possible culprit early in the troubleshooting process.

What is SELinux, Exactly?

At its core, SELinux is a set of rules that tell applications what they can and can’t do. SELinux is separate from the regular Linux file permissions model and is therefore able to protect against issues like misconfigured permissions or privilege escalation exploits. In order for an operation to succeed on an SELinux-enabled system, it must be permitted by file permissions as well as by the active SELinux policy.

Regular file permissions are a form of discretionary access control, or DAC. On the other hand, SELinux is a form of mandatory access control, or MAC. With DAC, a user or service can do anything they have permission to do, even if it’s something undesirable or dangerous. With MAC, malicious or dangerous actions can be stopped, even if a DAC policy would otherwise permit them to happen.

Here’s an example of why you’d want to keep SELinux enabled. Normally, Apache shouldn’t be able to read /etc/shadow, and the default file permissions prevent that from happening. However, if those permissions were misconfigured and Apache was configured to serve files from /etc, it would be possible for anyone with a web browser to download /etc/shadow. A properly configured SELinux policy would override both misconfigurations and prevent Apache from serving sensitive system files from /etc.

Putting Things in Context

Extra protection is great, but what happens when SELinux interferes when it shouldn’t? If SELinux is interfering with something “normal” that should otherwise work, chances are you have one simple problem: incorrect file security contexts. Security contexts are how SELinux categorizes files and decides which applications can access them. By default, security contexts are applied to files based on their location. For example, files in home directories get different security contexts from files in /etc or /tmp.

You can inspect a file’s security context with ls -Z, but you’re probably better off using restorecon to reset contexts to their default values if you suspect a problem. To save time, you can run restorecon -rv /path/to/directory to recursively reset the security contexts for an entire directory. If things are bad enough, you can relabel your entire filesystem by running touch /.autorelabel and then rebooting.

The restorecon tool was the solution to problems #1 and #2 from the list at the beginning of this post. Incorrect security contexts can be applied when files are restored from a backup or copied from a nonstandard location.

Adjusting the Policy

In most mainstream Linux distributions, the default SELinux policy is carefully crafted by a group of upstream maintainers. Creating a perfect one-size-fits-all policy is impossible, so the maintainers provide built-in policy exceptions in the form of SELinux booleans. SELinux booleans can be easily enabled or disabled to cover common use cases where the default SELinux policy falls short. If you have an SELinux problem that can’t be fixed by restoring default file security contexts, you should check to see if an available SELinux boolean covers your use case.

You can use getsebool to retrieve a list of available booleans on your system and then use setsebool to enable or disable them. Alternatively, you can use semanage to see more detailed information about available booleans. Examples of SELinux booleans include:

• use_nfs_home_dirs: Support NFS home directories.
• httpd_can_network_connect: Allow HTTPD scripts and modules to connect to the network.
• ftpd_full_access: Allow full filesystem access over FTP.

Rewriting the Policy

If fixing security contexts and enabling booleans hasn’t worked, ask yourself if you’re doing something abnormal. “Abnormal” in this context might include running a service on a nonstandard port, serving web files from an unconventional location, or moving config files out of their default directory. If you are, there’s a good chance your system’s default SELinux policy won’t cover your use case.

Before you proceed, you should think hard about what benefit you’re getting from running a nonstandard configuration. Standards exist for good reasons: troubleshooting is easier, malicious activity is simpler to detect, and applications can be configured to behave more predictably. With that said, there’s plenty of vendor software out there that relies on an “abnormal” configuration to work properly.

If you’ve evaluated your configuration and decided to proceed, you have two options. First, you may have discovered a bug in your platform’s SELinux policy, which means you should submit a bug report so that the policy can be fixed upstream. This is the course I ended up pursuing for the OpenDKIM issue mentioned above, and the Red Hat maintainers updated the upstream policy after a few months.

Alternatively, you can write and compile a custom SELinux policy module. This is not as difficult as it sounds, as audit2allow can generate SELinux modules directly from audit log entries. A brief description of how to make use of the audit log is below, but a full explanation is beyond the scope of this post.

The Audit Log

By default, SELinux violations are logged to the audit log, which is generally located at /var/log/audit/audit.log. The best way to troubleshoot potential SELinux issues is to consult the audit log, but the default log format is not particularly user-friendly and raw entries are not always easy to understand. Instead of reading the audit log file directly, you can search the log with ausearch or generate comprehensive, human-readable reports from it with sealert. Additional resources for how to use those tools are provided at the bottom of this post.

Wrapping Up

SELinux has been around for a long time, and many mainstream Linux distributions now ship with robust SELinux policies that cover a range of use cases. Additionally, configuration management tools like Puppet can automatically set SELinux contexts for you and help you avoid inadvertently mislabeling files.

That said, the default SELinux policy can’t possibly cover all possible use cases, so you may still need to enable SELinux booleans or compile custom policy modules to make SELinux work for you. In any case, you should avoid disabling it outright, especially if you’re running a derivative of Fedora such as RHEL or CentOS where SELinux is intended to be the primary form of mandatory access control.

References:

• What is SELinux? - Red Hat
• HowTos/SELinux - CentOS Wiki
• Getting started with SELinux :: Fedora Docs
• Troubleshooting SELinux :: Fedora Docs
• Basic SELinux Troubleshooting in CLI - Red Hat Customer Portal
• Using SELinux - Red Hat Enterprise Linux 8 - Red Hat Customer Portal

Affected users on Windows endpoints with Bitdefender Antivirus installed may receive the following error when they try to log on to a remote PC or server with Network Level Authentication (NLA) enabled:

An authentication error has occurred.
The Local Security Authority cannot be contacted.
This could be due to an expired password.

While an expired password or a server-side misconfiguration can cause this error, it may also indicate a client-side issue. In this case, the error appears to be caused by Bitdefender Antivirus replacing the remote computer’s certificate in order to inspect encrypted RDP traffic. This process breaks Network Level Authentication and causes the connection to fail.

Solution: Add File-Level Exclusions for MSTSC

One workaround is to add file-level exclusions in Bitdefender for both the 64-bit and 32-bit versions of the Windows RDP client:

• C:\Windows\system32\mstsc.exe
• C:\Windows\syswow64\mstsc.exe

This is not an ideal solution, but the free version of Bitdefender Antivirus has a limited control panel and does not provide alternative workarounds.

References:

• Bitdefender Antivirus Free Edition breaking RDP : BitDefender
• Remote Desktop Connection Issue - Microsoft Community
• Bitdefender Antivirus Free - remote Desktop block - The Bitdefender Expert Community
• AWS ec2 windows login error - Stack Overflow

If you’re running Stata on a standalone Linux server or an HPC cluster, you may be interested in having Stata update itself without any user interaction. This is especially useful if Stata users do not have permission to update the software themselves, as is often the case on shared Linux systems.

We can enable true automatic updates with a cron job and a Stata batch mode hack:

0 0 * * 0 echo 'update all' | /usr/local/stata19/stata > /dev/null

Adding this line to root’s crontab will cause the update all command to be run every Sunday at 12am. Standard output is piped to /dev/null to prevent cron from sending unnecessary emails.

As always, think carefully before enabling automatic updates for mission-critical pieces of software. However, StataCorp’s quality control has historically been pretty good.

Starting next month, Microsoft plans to use Office 365 ProPlus to push a browser extension for Google Chrome that will change users’ default search engines to Bing. Version 2002 of Office 365 ProPlus will forcibly install the Microsoft Search in Bing extension for all Chrome users who do not already use Bing as their default search engine.

Understandably, many system administrators are frustrated with the announcement, as unwanted browser extensions that change end-user settings are usually considered malware and are blocked accordingly. In fact, Microsoft’s own security tools already block dozens of programs that exhibit similar behavior.

On GitHub, users are responding to the change by opening issues in the OfficeDocs-DeployOffice repository. So far, it does not appear that Microsoft has responded to this influx of unsolicited feedback outside of publishing a blog post extolling the virtues of Bing.

Who Is Affected?

At this point, only businesses that have deployed Office 365 ProPlus are affected. Depending on the organization’s Office 365 license, ProPlus is the version of Office delivered to end-users when they install Office from the office.com portal. According to Microsoft, not all Office 365 plans include the ProPlus version of Office:

This extension is included only with Office 365 ProPlus. It isn’t included with Office 365 Business, which is the version of Office that comes with certain business plans, such as the Microsoft 365 Business plan and the Office 365 Business Premium plan.

Firefox Is Next

According to Microsoft, a similar extension for Firefox is also on the way:

Support for the Firefox web browser is planned for a later date. We will keep you informed about support for Firefox through the Microsoft 365 Admin Center and this article.

Removing The Extension

By making the extension an opt-out feature, Microsoft is putting the onus on system administrators to deploy a method for blocking its installation. While there are official ways to prevent the extension from being installed, there is no easy Microsoft-supported method for removing the extension once it has already been deployed. Instead, Microsoft recommends running the following command as an administrator on each affected machine using a script:

C:\Program Files (x86)\Microsoft\DefaultPackPC\MainBootStrap.exe uninstallAll

It should also be possible to blacklist the extension with the 3rd party Group Policy templates for Chrome and Firefox provided by Google and Mozilla.

Unfortunately, Group Policy and other enterprise management tools do not always apply to BYOD devices, leaving users who install Office on their personal machines with little recourse except to notice and remove the extension on their own if they find it undesirable.

References:

• Microsoft Search in Bing and Office 365 ProPlus - Microsoft Docs
• Microsoft to force Chrome default search to Bing using Office 365 installer - The Verge
• Microsoft to forcibly install Bing search extension in Chrome for Office 365 ProPlus users - ZDNet
• Microsoft to Force Bing Search in Chrome for Office 365 ProPlus Users - BleepingComputer