stevedoria.net

The following procedure adds encryption to pre-installed Ubuntu 18.04 on Dell XPS 13 7390:

1. Within a console or terminal, sudo into root.

$ sudo su -

2. Create LUKS encrypted file container (20,000 Megabytes or 20GB, for example).

# dd status=progress if=/dev/zero bs=1M count=20000 of=/.hostname-home.img
# cryptsetup luksFormat /.hostname-home.img

3. Open LUKS encrypted file container.

# cryptsetup luksOpen /.hostname-home.img hostname-home

4. Format encrypted filesystem.

# mkfs.ext4 /dev/mapper/hostname-home

5. Move original /home content to temporary location.

# mkdir /root/home
# mv /home/* /root/home/.

6. Mount the encrypted filesystem.

# mount /dev/mapper/hostname-home /home

7. Move /home content into encrypted filesystem.

# mv /root/home/* /home/.
# rmdir /root/home

8. Unmount the encrypted container, potentially flushing (writing) pending data to disk.

# umount /home

9. Close the LUKS encrypted file container, potentially flushing (writing) pending data to disk.

# cryptsetup luksClose hostname-home

10. Add entry into /etc/crypttab.

# echo \
"hostname-home /.hostname-home.img - tries=0" \
>> /etc/crypttab

11. Add entry into /etc/fstab.

# echo \
"/dev/mapper/hostname-home /home ext4 defaults 0 0" \
>> /etc/fstab

I recently received my Dell XPS 13 7390 with pre-installed Ubuntu 18.04. My top concern is securing data such as private SSH keys and passwords saved by Internet browsers from the real possibility of losing my laptop to absent-mindedness or theft. My purist side insists on configuring full disk encryption by performing a fresh install from a publicly available Ubuntu download. My pragmatic side pushed me toward adopting the above procedure. Without the needed transparency from Dell on their additions to Ubuntu, it is difficult to determine whether a publicly available Ubuntu download will fully support the features of my new Dell XPS 7390. The above procedure encrypts any data writable by unprivileged users while remaining unprivileged. It introduces a basic layer of security while allowing enjoyment of a system configured by Dell.

As the holiday season nears, a new laptop for developing skills and personal projects is worth considering. The Dell XPS 13 7390, with an Intel® Core™ i7-10710U processor, is really enticing. Windows 10 Pro, an M.2 PCIe NVMe SDD, and non-touch display are motivating as well. As with other big purchases, a decision will require more than a month’s consideration.

Specifications:

• Processor: 10th Generation Intel® Core™ i7-10710U Processor (12MB Cache, up to 4.7GHz, 6 cores)
• Operating System: Microsoft Windows 10 Pro
• Memory: 16GB LPDDR3 2133MHz
• Hard Drive: 512GB M.2 PCIe NVMe SSD
• Display: 13.3″ FHD (1920×1080) Non-Touch Display

System.InvalidOperationException: Cross-thread operation not valid. Control "textBox1" accessed from a thread other than the thread it was created on.

The above exception was encountered while placing a function call with long execution time on a separate thread and having that thread update a TextBox with status updates. The issue arises, because “access to Windows Forms controls isn’t inherently thread-safe.”¹

Documentation by Microsoft discusses the following solutions:

• calling the Control.Invoke() method
• using a BackgroundWorker component
• setting Control.CheckforIllegalCrossThreadCalls property to false (unsafe)

Invoke() Method

This approach checks whether the currently running thread is the same thread that created the control. If the threads are different, then Invoke() is called to allow running a delegate in the control’s owner thread. Otherwise, the currently running thread is the owner of the control, and the control’s properties can be manipulated directly. This method is demonstrated by the following code snippet:

if (textBox1.InvokeRequired)
   textBox1.Invoke(
      new MethodInvoker(
         () => {textBox1.Text = "abc";} ) );
else
    textBox1.Text = "abc";

Using BackgroundWorker

BackgroundWorker raises three events: DoWork, ProgressChanged, and RunWorkerCompleted.

A DoWork event handler is where long duration functions are called away from the main thread. It runs in a thread separate from the thread that created the BackgroundWorker instance. Modifying a control’s properties from a DoWork event handler will throw System.InvalidOperationException().

The main thread usually creates user interface controls. It also maintains UI responsiveness typically by creating worker threads for lengthy functions. Because BackgroundWorker is likely created from the thread that creates user interface controls, and ProgressChanged and RunWorkerCompleted event handlers execute in the thread that creates BackgroundWorker, it is safe to modify UI controls from ProgressChanged and RunWorkerCompleted event handlers.

With the BackgroundWorker’s WorkerReportsProgress property set to true, event handlers for the BackgroundWorker’s DoWork event can call ReportProgress() to indirectly modify UI controls. ReportProgress() raises the ProgressChanged event, which causes calling of event handlers in the thread that created the BackgroundWorker.

The ReportProgress() method is overloaded. One version of ReportProgress() accepts an integer, which is typically used to represent a percentage of completion. The second version of ReportProgress() accepts an object as well as a percentage of completion. The version of ReportProgress() that accepts an object can be used by the DoWork event handler to send detailed data useful for updating UI controls.

A ProgressChanged event handler added to the BackgroundWorker by the main thread, can inspect the UserState property of the ProgressChangedEventArgs. This property is set to the object provided in the ReportProgress(int, object) call. To set textBox1.Text in the ongoing example, the DoWork event handler can call ReportProgress(0, “abc”) and the ProgressChanged event handler can cast the UserState property to a string and assign it to textBox1.Text:

private void backgroundWorker_ProgressChanged(
   object sender, ProgressChangedEventArgs e)
{
   string s = e.UserState as string;
   textBox1.Text = s;
}

Setting Control.CheckForIllegalCrossThreadCalls to false

Let’s not.

Using BackgroundWorker or the Invoke() method can be applied for different situations. The Invoke() method may be used by a worker thread to show a Modal dialog or MessageBox that prevents the main application form from receiving input while the dialog or MessageBox are displayed. BackgroundWorker allows lengthy methods to run in worker threads while providing feedback to the main thread. Both methods are acceptable mechanisms for cross-thread manipulation of Windows Forms.

Login attempts can be tracked in real time with the following command:

/bin/utmpdump -f /var/log/btmp

I received a Logwatch email reporting a “corruption detected in /var/log/btmp : XX time(s)” issue. By performing an Internet search for the reported issue, I found Gabriel Cánepa’s How to Monitor User Login History on CentOS with utmpdump. Cánepa describes utmpdump in depth and the fields in each utmpdump line entry.

The eight fields emitted by utmpdump are:

1. session identifier
2. PID
3. “~~” (runlevel change) | “bw” (bootwait process) | TTY | PTY
4. empty | username | reboot | runlevel
5. TTY | PTY
6. remote hostname | kernel version
7. remote IP address
8. timestamp