Category Archives: Ubuntu

Tesla Model 3 Modded To Run Ubuntu

140Mandak262Jamuna writes: CleanTechnica is reporting that someone hacked the infotainment system of a Tesla Model 3 and got root access and installed Linux distribution Ubuntu. Redditor trsohmers is able to show an Ubuntu command shell running alongside the Tesla OS. Since Tesla supports a browser that allows you to visit any site, could this be leveraged into remote hacks? It could also mean that if Tesla sells a long-range version of the Model 3, but limits it via software, people might try to remove the block. One could potentially get a 15-day trial of full self-driving for free and extend that 15-day window forever. At least he had some guts messing with $50,000 hardware that phones home all the time. Will Tesla brick his car to attempt to disprove the security issue?

Read more of this story at Slashdot.

Warning! Unprivileged Linux Users With UID > INT_MAX Can Execute Any Command

Hold tight, this may blow your mind… A low-privileged user account on most Linux operating systems with UID value anything greater than 2147483647 can execute any systemctl command unauthorizedly—thanks to a newly discovered vulnerability. The reported vulnerability actually resides in PolicyKit (also known as polkit)—an application-level toolkit for Unix-like operating systems that defines

HiR Information Report: OpenBSD VMM Hypervisor Part 4: Running Ubuntu (and possibly other distros)

TL;DR: you cheat.

I've been trying for almost a year to figure out how to get the cloud-init meta-data service to work with the Ubuntu Cloud image. I've asked on misc@ and other OpenBSD groups, and no one has an answer. The documentation is vague. If anyone ever figures out how to configure meta-data, let me know. I'd still like to give it a shot.

Last week, I rescued a server from a pile of computers destined to be scrapped and recycled. For me, it's the perfect setup for getting serious with OpenBSD VMM in my home lab. Two older Xeon E5-2620 CPUs and 128 GB of RAM. No hard drives, but it came with enough empty drive trays for getting started. I threw a pair of old SAS drives into it.

No surprise, OpenBSD just worked. This renewed my fervor for replicating a bunch of my cloud instances at home, and there's a lot of Ubuntu in use.

I decided to bite the bullet and just use qemu to do the installation and configuration of Ubuntu. Install qemu from packages:

doas pkg_add qemu

Download Ubuntu Server. I've actually used both 18.04 LTS and 16.04 LTS. I'm focusing on 16.04 for this because that's what I'm running on most of my EC2 instances.

Create a disk image.

vmctl create qcow2:ubuntu16lts.qcow2 -s 20G

Boot the ubuntu ISO and attach the new ubuntu disk image to qemu:

qemu-system-x86_64 -boot d -cdrom ~/Downloads/ubuntu-16.04.5-server-amd64.iso -drive file=ubuntu16lts.qcow2,media=disk -m 640

Install Ubuntu as usual. I didn't bother adding anything other than the SSH server during installation. qemu is really slow on OpenBSD, but it works... eventually. When the install is done, shut down and then restart qemu without the installation ISO attached.

qemu-system-x86_64 -drive file=ubuntu16lts.qcow2,media=disk -m 640

Log in with the user-level account you created. There are only two things to tweak before it's ready to run in vmm: Configuring the serial console, and the network interface.

Under qemu, Ubuntu sees "ens3" as the network interface. Under vmm, the network interface is "enp0s3". Change "ens3" to "enp0s3" in /etc/network/interfaces if you're using 16.04. On Ubuntu 18.04, you must instead change the "netplan" config file in /etc/netplan/50-cloud-init.yaml with the same kind of change, ens3 to enp0s3.

To configure the serial console, edit /etc/default/grub and change this line:



GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8"

then run

sudo update-grub

Shut down qemu again. Your disk image is basically ready to go under vmm.

To save the trouble of having to mess with qemu again, I recommend creating derivative images of the one you just created, and using those for vmm.

vmctl create qcow2:ubuntu16lts-1.qcow2 -b ubuntu16lts.qcow2

Add the new disk image to a configuration clause in /etc/vm.conf on your OpenBSD host system. Mine looks like this:

vm "Ubuntu16.04" {
        owner axon
        memory 4096M
        disk "/home/axon/vmm/ubuntu16lts-1.qcow2"
        interface {
                switch "local"
                lladdr fe:e1:ba:f0:eb:b0

For more information about setting up switches and networks in vmm, see Part 2 of my VMM series.

Voila! Ubuntu in VMM!

Although the configuration files you must edit to make it work might vary, you can do the same thing and it may very well work for text-mode-only distributions.

I actually didn't need to use qemu to get arch linux installed in vmm, but it was somewhat tedious to do entirely in vmm, and it took me a few tries to get it right. Qemu might have been easier.

HiR Information Report

Mark Shuttleworth Reveals Ubuntu 18.04 Will Get a 10-Year Support Lifespan

At the OpenStack Summit in Berlin last week, Ubuntu Linux founder Mark Shuttleworth said in a keynote that Ubuntu 18.04 Long Term Support (LTS) support lifespan would be extended from five years to 10 years. "I'm delighted to announce that Ubuntu 18.04 will be supported for a full 10 years," said Shuttleworth, "In part because of the very long time horizons in some of industries like financial services and telecommunications but also from IoT where manufacturing lines for example are being deployed that will be in production for at least a decade." ZDNet reports: Ubuntu 18.04 released in April 2018. While the Ubuntu desktop gets most of the ink, most of Canonical's dollars comes from server and cloud customers. It's for these corporate users Canonical first extended Ubuntu 12.04 security support, then Ubuntu 14.04's support, and now, preemptively, Ubuntu 18.04. In an interview after the keynote, Shuttleworth said Ubuntu 16.04, which is scheduled to reach its end of life in April 2021, will also be given a longer support life span. When it comes to OpenStack, Shuttleworth promised again to support versions of OpenStack dating back to 2014's IceHouse. Shuttleworth said, "What matters isn't day two, what matters is day 1,500." He also doubled-down on Canonical's promise to easily enable OpenStack customers to migrate from one version of OpenStack to another. Generally speaking, upgrading from one version of OpenStack is like a root canal: Long and painful but necessary. With Canonical OpenStack, you can step up all the way from the oldest supported version to the newest one with no more than a second of downtime.

Read more of this story at Slashdot.