Home Blog Page 401

Windows for Linux Nerds

I am super excited about Windows Subsystem for Linux. It is one of the coolest pieces of tech I’ve seen since I started using Docker.

First, a little background on how WSL works…

You can learn a lot more about this from the Windows Subsystem for Linux Overview. I will go over some of the parts I found to be the most interesting.

The Windows NT kernel was designed from the beginning to support running POSIX, OS/2, and other subsystems. In the early days, these were just user-mode programs that would interact with ntdll to perform system calls. Since the Windows NT kernel supported POSIX there was already a fork system call implemented in the kernel. However, the Windows NT call for fork,NtCreateProcess, is not directly compatible with the Linux syscall so it has some special handling you can read about more under System Calls.

There are both user and kernel mode parts to WSL. Below is a diagram showing the basic Windows kernel and user modes alongside the WSL user and kernel modes.

Read more at Jessie Frazelle’s blog

Protecting Code Integrity with PGP — Part 4: Moving Your Master Key to Offline Storage

In this tutorial series, we’re providing practical guidelines for using PGP. You can catch up on previous articles here:

Part 1: Basic Concepts and Tools

Part 2: Generating Your Master Key

Part 3: Generating PGP Subkeys

Here in part 4, we continue the series with a look at how and why to move your master key from your home directory to offline storage. Let’s get started.

Checklist

  • Prepare encrypted detachable storage (ESSENTIAL)

  • Back up your GnuPG directory (ESSENTIAL)

  • Remove the master key from your home directory (NICE)

  • Remove the revocation certificate from your home directory (NICE)

Considerations

Why would you want to remove your master [C] key from your home directory? This is generally done to prevent your master key from being stolen or accidentally leaked. Private keys are tasty targets for malicious actors — we know this from several successful malware attacks that scanned users’ home directories and uploaded any private key content found there.

It would be very damaging for any developer to have their PGP keys stolen — in the Free Software world, this is often tantamount to identity theft. Removing private keys from your home directory helps protect you from such events.

Back up your GnuPG directory

!!!Do not skip this step!!!

It is important to have a readily available backup of your PGP keys should you need to recover them (this is different from the disaster-level preparedness we did with paperkey).

Prepare detachable encrypted storage

Start by getting a small USB “thumb” drive (preferably two!) that you will use for backup purposes. You will first need to encrypt them:

For the encryption passphrase, you can use the same one as on your master key.

Back up your GnuPG directory

Once the encryption process is over, re-insert the USB drive and make sure it gets properly mounted. Find out the full mount point of the device, for example by running the mount command (under Linux, external media usually gets mounted under /media/disk, under Mac it’s /Volumes).

Once you know the full mount path, copy your entire GnuPG directory there:

$ cp -rp ~/.gnupg [/media/disk/name]/gnupg-backup

(Note: If you get any Operation not supported on socket errors, those are benign and you can ignore them.)

You should now test to make sure everything still works:

$ gpg --homedir=[/media/disk/name]/gnupg-backup --list-key [fpr]

If you don’t get any errors, then you should be good to go. Unmount the USB drive and distinctly label it, so you don’t blow it away next time you need to use a random USB drive. Then, put in a safe place — but not too far away, because you’ll need to use it every now and again for things like editing identities, adding or revoking subkeys, or signing other people’s keys.

Remove the master key

The files in our home directory are not as well protected as we like to think. They can be leaked or stolen via many different means:

  • By accident when making quick homedir copies to set up a new workstation

  • By systems administrator negligence or malice

  • Via poorly secured backups

  • Via malware in desktop apps (browsers, pdf viewers, etc)

  • Via coercion when crossing international borders

Protecting your key with a good passphrase greatly helps reduce the risk of any of the above, but passphrases can be discovered via keyloggers, shoulder-surfing, or any number of other means. For this reason, the recommended setup is to remove your master key from your home directory and store it on offline storage.

Removing your master key

Please see the previous section and make sure you have backed up your GnuPG directory in its entirety. What we are about to do will render your key useless if you do not have a usable backup!

First, identify the keygrip of your master key:

$ gpg --with-keygrip --list-key [fpr]

The output will be something like this:

pub   rsa4096 2017-12-06 [C] [expires: 2019-12-06]
     111122223333444455556666AAAABBBBCCCCDDDD
     Keygrip = AAAA999988887777666655554444333322221111
uid           [ultimate] Alice Engineer <alice@example.org>
uid           [ultimate] Alice Engineer <allie@example.net>
sub   rsa2048 2017-12-06 [E]
     Keygrip = BBBB999988887777666655554444333322221111
sub   rsa2048 2017-12-06 [S]
     Keygrip = CCCC999988887777666655554444333322221111

Find the keygrip entry that is beneath the pub line (right under the master key fingerprint). This will correspond directly to a file in your home .gnupg directory:

$ cd ~/.gnupg/private-keys-v1.d
$ ls
AAAA999988887777666655554444333322221111.key
BBBB999988887777666655554444333322221111.key
CCCC999988887777666655554444333322221111.key

All you have to do is simply remove the .key file that corresponds to the master keygrip:

$ cd ~/.gnupg/private-keys-v1.d
$ rm AAAA999988887777666655554444333322221111.key

Now, if you issue the –list-secret-keys command, it will show that the master key is missing (the # indicates it is not available):

$ gpg --list-secret-keys
sec#  rsa4096 2017-12-06 [C] [expires: 2019-12-06]
     111122223333444455556666AAAABBBBCCCCDDDD
uid           [ultimate] Alice Engineer <alice@example.org>
uid           [ultimate] Alice Engineer <allie@example.net>
ssb   rsa2048 2017-12-06 [E]
ssb   rsa2048 2017-12-06 [S]

Remove the revocation certificate

Another file you should remove (but keep in backups) is the revocation certificate that was automatically created with your master key. A revocation certificate allows someone to permanently mark your key as revoked, meaning it can no longer be used or trusted for any purpose. You would normally use it to revoke a key that, for some reason, you can no longer control — for example, if you had lost the key passphrase.

Just as with the master key, if a revocation certificate leaks into malicious hands, it can be used to destroy your developer digital identity, so it’s better to remove it from your home directory.

cd ~/.gnupg/openpgp-revocs.d
rm [fpr].rev

Next time, you’ll learn how to secure your subkeys as well. Stay tuned.

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

One Week Until Embedded Linux Conference + OpenIoT Summit in Portland: Will You Join Us?

In just one week, you could be in good company, joining 900+ developers, architects, practitioners, and Embedded Linux and Industrial IoT technologists.

Sign up for ELC/OpenIoT Summit updates to get the latest information:

Taking place March 12-14 at the Hilton Portland, ELC + OpenIoT Summit will deliver:

  • 100+ technical sessions: Conference sessions covering a range of technical topics from open industrial IoT solutions to embedded Linux development, led by experts from ARM, Dell, Intel, Microsoft, and many more.

  • Birds of a Feather Sessions (BoFs): Unconference sessions, organized by Yocto Project, OpenEmbedded, Open Source Foundries, Eclipse Foundation, Bootlin, and more, give you the opportunity to collaborate with other leading professionals.

  • Onsite Attendee Reception: Enjoy drinks and light bites as you connect and engage with other attendees while checking out the latest technologies in the ELC Technical Showcase.

  • *New* Embedded Apprentice Linux Engineer Track: This brand new track, featuring nine seminars over three days and designed for embedded engineers transitioning to Linux, includes both guided training and hands on lab time to practice skill building using a PocketBeagle board. Take as many or as few seminars as you need to hone the skills you need. Additional registration fee of $75.

  • Yocto Project Developer Day North America 2018: A one-day, hands-on training event that connects you directly to leading Yocto Project developers who will guide you through the creation of custom-built Linux distribution for embedded devices. Additional registration fee of $209.

  • The Closing Game: A perennial favorite – the closing game is part trivia, part pop culture, all fun, helping to close out this great event.

REGISTER NOW >>

 

​Kubernetes Graduates to Full-Fledged, Open-Source Program

At the Open Source Leadership Summit (OSLS), the Cloud Native Computing Foundation (CNCF), which sustains and integrates open-source, cloud native technologies such as Prometheus and containerd, and Chen Goldberg, Google Cloud’s director of engineering, announced that Kubernetes is the first project to graduate from the CNCF.

In her OSLS keynote speech, Goldberg explained there were numerous reasons Kubernetes had become successful. One of the most important, she said, “For Google, open-source software is part of the strategy, it’s not a side-gig. From the start Kubernetes upstream was also investing in Google Kubernetes Engine (GKE) and vice-versa. It’s about helping users.” And, “Community before product, community before company. And value diversity in that community,” Goldberg added.

Read more at ZDNet

Register Now to Save $600 for Open Networking Summit — Price Increases Sunday, March 11

ONS is the epicenter of idea exchange, decision making and project mapping across the open networking ecosystem. Attend this year, and join 2,000 architects, developers, and thought leaders to pave the future of networking integration, acceleration and deployment.

VIEW THE FULL SCHEDULE >>

You have 3 days left to save $605 on registration. Register by end of day on Saturday, March 10!

REGISTER NOW >>

Read more at The Linux Foundation

Cilium 1.0.0-rc4 Released: Transparently Secure Container Network Connectivity Utilising Linux BPF

Cilium is open source software for transparently securing the network connectivity between application services deployed using Linux container management platforms like Docker and KubernetesCilium 1.0.0-rc4 has recently been released, which includes: the Cloud Native Computing Foundation (CNCF)-hosted Envoy configured as the default HTTP/gRPC proxy; the addition of a simple health overview for connectivity and other errors; and an improved scalable kvstore interaction layer.

Microservices applications tend to be highly dynamic, and this presents both a challenge and an opportunity in terms of securing connectivity between microservices. Modern approaches to overcoming this issue have coalesced around the CNCF-hosted Container Network Interface (CNI) and the increasingly popular “service mesh” technologies, such as Istio and Conduit. According to the Cilium documentation, traditional Linux network security approaches (such as iptables) filter on IP address and TCP/UDP ports. However, the highly volatile life cycle of containers and IP addresses cause these approaches to struggle to scale alongside the application as the large number of load balancing tables and access control lists must be updated continually.

Read more at InfoQ

Automated Provisioning in Kubernetes

When deploying applications in a Kubernetes cluster, certain types of services are commonly required. Many applications require a database, a storage service, a message broker, identity management, and so on. You have enough work on your hands containerizing your own application. Wouldn’t it be handy if those other services were ready and available for use inside the cluster?

The Service Catalog

Don’t get stuck deploying and managing those other services yourself; let the Service Catalog do it for you. The Kubernetes Service Catalog README states:

“The end-goal of the service-catalog project is to provide a way for Kubernetes users to consume services from brokers and easily configure their applications to use those services, without needing detailed knowledge about how those services are created or managed.”

Read more at OpenSource.com

Tutorial: Tracing Python Flask requests with OpenTracing

A transaction trace is a GPS system for web performance: it paints a rich picture of the flow of a web request through your code.

So, why doesn’t everybody trace? I believe there are two reasons:

  1. Complex instrumentation: Adding in-app tracing instrumentation is more involved than calling logger.info() for logging or statsD_client.incr() for metrics.
  2. Vender lockin: You aren’t committing to a vendor when you log and record metrics: you can easily swap out different services to aggregate your logs and store your metrics. Even though APM vendor tracing libraries are remarkably similar, there hasn’t been a vendor-neutral standard for tracing. Adding complex, vendor-specific instrumentation can feel like a deeper commitment than one desires.

OpenTracing, a vender-neutral tracing API

Enter OpenTracing, a vendor-neutral open standard for distributed tracing. OpenTracing loosens the chains on tracing instrumentation: if we trace our method calls via OpenTracing APIs, we can swap out our tracing vendors just like logging and metrics!

Read more at Scout

Submit a Proposal to Speak at OS Summit Japan and Automotive Linux Summit By March 18

Open Source Summit Japan and Automotive Linux Summit 2018 are once again co-located and will be held June 20-22 at the Tokyo Conference Center Ariake in Tokyo. Both events offer participants the opportunity to learn about the latest projects, technologies, and developments taking place across the open source ecosystem, and specifically in the Automotive Linux arena.

The deadline to submit a proposal is just 3 weeks away on Sunday, March 18, 2018. Don’t miss the opportunity to educate and influence hundreds of technologists and open source professionals by speaking at one of these events.

Read more at The Linux Foundation

Kubernetes Ingress: NodePort, Load Balancers, and Ingress Controllers

A fundamental requirement for cloud applications is some way to expose that application to your end users. This article will introduce the three general strategies in Kubernetes for exposing your application to your end users, and cover the various tradeoffs of each approach. I’ll then explore some of the more sophisticated requirements of an ingress strategy. Finally, I’ll give some guidelines on how to pick your Kubernetes ingress strategy.

Ingress in Kubernetes

In Kubernetes, there are three general approaches to exposing your application.

  • Using a Kubernetes service of type NodePort, which exposes the application on a port across each of your nodes
  • Use a Kubernetes service of type LoadBalancer, which creates an external load balancer that points to a Kubernetes service in your cluster
  • Use a Kubernetes Ingress Resource

Read more on Medium