Here are the steps to install Fedora 29 (armhfp) on the Orange PI Zero, from a Fedora 29 desktop. “opz” will be used throughout post to avoid typing “Orange Pi Zero” repeatedly.

Prepare sdcard on desktop

Perform these steps on your Fedora 29 desktop to prepare the sdcard that will be used in the opz.

• Download Fedora 29 Minimal Image for armv7 from https://arm.fedoraproject.org/
• Install ARM image tool packages

  sudo dnf install uboot-images-armv7 arm-image-installer

• Install image to sdcard. Replace “sdX” with location of your sdcard and adjust paths to ssh key and downloaded image as appropriate.

  sudo arm-image-installer --media /dev/sdX --target=orangepi_zero --image=Fedora-Minimal-armhfp-29-1.2-sda.raw.xz --resizefs --addkey=.ssh/id_rsa.pub --relabel

Boot Orange Pi Zero

• Eject the sdcard from desktop and insert into the opz.
• Connect RJ45 ethernet to opz.
• Connect 5V USB power to boot opz.
• Monitor DHCP server to determine IP address supplied to opz.
• SSH as root to IP address.

Post boot config

• Disable firstboot. If you connect to opz via serial connection, you’ll see the console is waiting for you to create a user and/or set root password. The initial-setup service is responsible for this.

  systemctl disable initial-setup

• Reboot

Your Orange Pi Zero is now running Fedora 29 (Minimal), and can only be accessed by IP address as root with SSH key.

#fedora #gpd #pocket2 #linux

Of course, immediately after I get Fedora 28 running on my new Pocket 2, what happens ?  Fedora 29 Beta is released!  So, here are my notes on getting Fedora 29 Beta running on the GPD Pocket 2.

Installing Fedora 29 Beta

1. Obtain the x86_64 Live ISO and write it to a USB drive
2. Boot from the USB drive using F12 to access the boot menu
3. The desktop will begin rotated sideways (just like with Fedora 28), but we can fix this.  Bring up Display Settings and do the following:
   • Select “Orientation” = “Portrait Left”, noting this gives an error
   • Select “Resolution” = 864×1152 (the lowest resolution)
   • Select original resolution of 1200×1920 again. This clears the error and activates the “Apply” button.
   • Click Apply and display should be properly oriented.
4. Perform the Fedora installation like normal
5. Reboot
6. The screen orientation will be sideways again.
7. Run through initial setup (sideways) to create user account
8. Once logged in as your new user, use the steps above in item 3 to correct the screen orientation
9. If you find the font and other UI elements to be too small on this 7″ screen,. then you’ll want to enable fractional scaling. Enter the following at the terminal:

   gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

10. Log out, log in, and enter the Display Settings again. You should now see an option for “Scale”. I find 150% to be the smallest comfortable on this small screen.
11. If you want bigger, edit “~/.config/monitors.xml” and set the scale to 2

    <scale>2</scale>

12. The font can also be scaled up by installing gnome-tweaks, running “Tweaks” and changing “Fonts->Scaling Factor”
13. Open a terminal, and copy the monitor configuration so that the GDM login screen also has proper orientation and scaling:

    sudo cp ~/.config/monitors.xml /var/lib/gdm/.config/

14. We can correct the orientation of the text console during boot by modifying a kernel parameter in Grub.
    • Edit /etc/default/grub to modify the GRUB_CMDLINE_LINUX variable, appending “fbcon=rotate:1” to the end
    • grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
15. Reboot

What’s left ?

• The plymouth screens during boot are still sideways, including the LUKS password prompt.  There appears to be upstream patches to correct this.

I read quite often about how a minimal operating system, with all things unnecessary for its expected functionality removed, is “more secure” because of the minimal attack surface.  While there is definitely something to be said for reducing the attack surface, having a minimal OS is not necessarily a good security practice.

“But Matt, if I don’t need something, then I should remove it so that an attacker can’t attack it, right?”  Maybe — it depends on how we define “need”.

If you are running a web server, do you need a mail server, or a print server, or a FTP server also running on that same system?  Probably not.  Remove those extraneous services from your deployment.

If you are running a web server, do you need a firewall ?  Well, the firewall doesn’t help you deliver web pages.  But I think many will accept that removing the firewall for the sake of minimality would be silly.  This is the other end of the spectrum, but helps illustrate the point that pure minimalism can actually negatively impact the security posture.

If you are running a web server, do you need a file system integrity monitor (FSIM) or other secondary defenses?  This is where we start getting into a fuzzy area.  I would argue that you should keep security tooling like an FSIM on your server.  The minimal footprint may help reduce the attack surface, but it will never be zero.  An attacker may still find a way in.  And when they do, you need additional layers (like FSIMs, EP, AV, MAC/SELinux, etc) to mitigate their impact and determine what they have done.  Don’t remove these tools from your OS deployment simply because you have a goal of minimally-sized functioning server.

If you are running a web server, do you need tcpdump, performance co-pilot, puppet, zabbix agent, splunk agent, or other operational tooling?  For normal day to day activity, you should never need these tools.  But occasionally, something will break, or something needs to be changed.  You will need tools that let you troubleshoot and fix, or that have been monitoring and collecting data for a period of time.  And if those tools aren’t already installed, you may not be able to install them during a problem.  Have you ever tried troubleshooting a network problem on a system where you can’t run “yum install tcpdump” because of the network problem?  While these tools are not security tools specifically, these are tools that are operationally necessary.  Consider keeping these tools, at least the critical subset of them, in your OS deployment.

If you are running a web server, do you need perl, python, ruby, and other scripting languages installed?  This requires deeper digging – do any of the tools that you’ve identified from the above scenarios require those languages?  Were they written in perl, python, or ruby, or require those languages for extra functionality ?  Tracing these dependencies can lead to a list of software that you may not have initially considered required, but due to choices of tools are not a requirement.  Assess this carefully, balancing your choice of tools against their requirements, but recognize that you may have to include some of these scripting languages, just to avoid creating security and operational impacts as described earlier.

So remember – your security posture cannot simply be measured by how small the OS deployment is.  Removing security tools from your OS can negatively impact your security posture, and removing operational tools from your OS can negatively impact your operational risk.  Before you start taking a scalpel to your OS with a goal of carving down to the smallest possible size, make sure you take into account your security and operational considerations, and the dependencies they pull in.

I’ve recently been playing with OpenWRT, and decided to see if I could use Ansible to manage it.  From a basic install of OpenWRT, here is what needs to be done to be able to manage with Ansible:

• Use the WebUI to upload your SSH public key
• Install a few packages, either via the WebUI or from the CLI with “opkg install”
  • python-light
  • python-logging
  • python-crypto
• On your Ansible control node, specify the following in your ansible.cfg (dropbear does not include the sftp subsystem):

  [ssh_connection]
  scp_if_ssh = True

• Give it a test (output trimmed below for brevity):

  $ ansible -msetup -i [email protected], all
  [email protected] | SUCCESS => {
  "ansible_facts": {
    ...
    "ansible_architecture": "mips",
    ...
    "ansible_distribution": "LEDE",
    "ansible_distribution_version": "17.01.4, Reboot",
    ...
    "ansible_os_family": "LEDE",
    "ansible_pkg_mgr": "opkg",
    ...
    }
  }

 

I’ve spent a few hours banging my head against something that – in retrospect – is pretty obvious: “delegate_to” does not respect the “ansible_user” inventory variable.

Challenge

delegate_to is used to execute a task on a host other than the one targeted for playbook execution.  Compare these three tasks:

- command: echo Hello World

- command: echo Hello World
  delegate_to: localhost

- command: echo Hello World
  delegate_to: random.example.com

The first task will execute “echo Hello World” on the system in the inventory that this playbook is being called for.

The second task will simply execute the ‘echo’ on the system running the ansible playbook.

The third task will connect to “random.example.com” to execute the echo.  But, notably, “random.example.com” doesn’t even need to be in your inventory, and so the connection to “random.example.com” does not use any inventory variables, such as “ansible_user”.

“delegate_to” will respect the global “remote_user”, but I often use different non-root user accounts for Ansible connections.  So, if “delegate_to” doesn’t respect “ansible_user”, and if I can’t set a useful global “remote_user”, what can I do?

Solution

Once I figured this out, it’s pretty obvious in hindsight:

- command: echo Hello World
  delegate_to: my_remote_user@random.example.com

“delegate_to” allows the user to be part of the connection string.  In this example, I will connect to ‘random.example.com’ as the ‘my_remote_user’ id.  This could also be replaced with an inventory variable for the host the playbook is run for.

If you are in I.T., you’ve heard about Meltdown and Spectre by now.  So – what are you going to do about it?

1. Don’t panic, follow your existing High Priority Security Patching processes.
2. Start assessing, in your test environment, the performance impact of patches against your performance-sensitive workloads, especially those with heavy disk I/O or network I/O. (Red Hat customers – check out our assessment of performance impacts using our patches).  Make sure you are aware of the new “nopti” kernel parameter, but be *very* judicious in it’s use.
3. Prioritize multi-user systems, especially if any potential users are not trusted.
4. Prioritize patching of shared compute resources, such as public or private clouds, especially where the host is carrying workloads (applications, VMs) from multiple security or compliance domains.
5. This is not (yet) known to be remotely exploitable, so systems that are not sharing resources and are not accessed by multiple users can have a slightly lesser priority.  Given the performance impact referenced in #2 above, and given that performance-sensitive workloads are often run isolated from other workloads, balance an appropriate amount of time in testing the impact of the patches to your workload.

 

So, don’t panic, follow process, understand the impact to your environment – just like you should in any security event.

 

• https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
• https://access.redhat.com/security/vulnerabilities/speculativeexecution
• https://access.redhat.com/node/3307751
• https://lwn.net/Articles/741878/