This week Jonathan Bennett and Rob Campbell chat with Brodie Robertson about Linux, Wayland, YouTube, Microsoft’s Windows Recall and more. Is Linux ready for new users? Is Recall going to kick off a migration? All this and more!
Continue reading “FLOSS Weekly Episode 786: What Easy Install Script?”
There was a time when real system administrators just logged into Unix systems as root. But as we all know — with great power comes great responsibility. It’s too easy to do terrible things when you are really just trying to do normal work, and, on top of that, malicious software or scripts can do naughty things without you noticing. So common practice quickly changed to where an administrator had a personal account but then had a way to run certain programs “as root” which means you had to deliberately decide to wield your power.
Before long, people realized you don’t even need a root login account. That way, an attacker can’t try to log into root at all. Sure, they could still compromise your account, but a random hacker knows you might have a root user, but it is harder to guess that your login ID is JTKirkJr or whatever.
There are other ways to control what users can do, but many Linux and Unix installations still use this model. The root can do everything but login, and specific users get the privilege to do certain things.
It may be a very long time since some readers have installed a copy of Windows, but it appears at one point during the installation there’s a step that asks you which OS version you would like to install. Normally this is populated by whichever Windows flavours come on the install medium, but [Naman Sood] has other ideas. How about a Windows installer with Alpine Linux as one of the choices? Sounds good to us.
You can see it in action in the video below the break. Indeed Alpine Linux appears as one of the choices, followed by the normal Windows licence accept screen featuring the GPL instead of any MS text. The rest of the installer talks about installing Windows, but we can forgive it not expecting a Linux install instead.
So, the question we’re all asking is: how is it done? The answer lies in a WIM file, a stock Windows image which the installer unpacks onto your hard drive. The Linux distro needs to be installable onto an NTFS root partition, and to make it installable there’s a trick involving the Windows pre-installation environment.
This is an amusing hack, but the guide admits it’s fragile and perhaps not the most useful. Even so, the sight of Linux in a Windows installer has to be worth it.
The UK has the answer to all our IoT problems: banning bad default passwords. Additionally, the new UK law requires device makers to provide contact info for vulnerability disclosures, as well as a requirement to advertise vulnerability fix schedules. Is this going to help the security of routers, cameras, and other devices? Maybe a bit.
I would argue that default passwords are in themselves the problem, and complexity requirements only nominally help security. Why? Because a good default password becomes worthless once the password, or algorithm leaks. Let’s lay out some scenarios here. First is the static default password. Manufacturer X makes device Y, and sets the devices to username/password admin/new_Complex_P@ssword1!. Those credentials make it onto a default password list, and any extra security is lost.
What about those devices that have a different, random-looking password for each device? Those use an algorithm to derive that password from the MAC address and/or serial number. That may help the situation, but the algorithm can be retrieved from the firmware, and most serial numbers are predictable in one way or another. This approach is better, but not a silver bullet.
So what would a real solution to the password problem look like? How about no default password at all, but no device functionality until the new password passes a cracklib complexity and uniqueness check. I have seen a few devices that do exactly this. The requirement for a disclosure address is a great idea, which we’ve talked about before regarding the similar EU legislation.
Continue reading “This Week In Security: Default Passwords, Lock Slapping, And Mastodown”
Last time, I gave a whirlwind introduction to a very small slice of systemd. If you aren’t comfortable with systemd services, timers, and mounts, you might want to read that now. Otherwise, press on to see a few interesting uses for custom systemd units, including running a few things on a schedule and automatically mounting a Raspberry Pi Zero.
Can you do every one of these things in a different way? Of course you can. I’m not debating the relative merits of using or not using systemd. However, unless you totally control your own environment, good chance you are going to have to interact with systemd at some point.
A few years ago, I talked about updating your remote DNS server with your public IP address. This lets you refer to a hostname like snoopy.hackaday.com and get back to your computer that often changes IP addresses. Sure, you can get services to do that for you, but you must either pay or agree to read ads on their site to keep your hostname going. This is all under your control. In the original post, I suggested using cron or NetworkManager to run the update script. I also hinted you could do it with systemd, but I didn’t tell you how. Let’s fix that.
I will confess. I started writing this post about some stupid systemd tricks. However, I wanted to explain a little about systemd first, and that wound up being longer than the tricks. So this Linux Fu will be some very fundamental systemd information. The next one will have some examples, including how to automount a Raspberry Pi Pico. Of course, by the end of this post, you’ll have only scratched the surface of systemd, but I did want to give you some context for reading through the rest of it.
Like many long-time Unix users, I’m not a big fan of systemd. Then again, I’m also waiting for the whole “windows, icon, mouse, pointer” fad to die down. Like it or not, systemd is here and probably here to stay for the foreseeable future. I don’t want to get into a flame war over systemd. Love it or hate it, it is a fact of life. I will say that it does have some interesting features. I will also say that the documentation has gotten better over time. But I will also say that it made many changes that perhaps didn’t need to be made and made some simple things more complicated than they needed to be.
In the old days, we used “init scripts,” and you can still do so if you are really motivated. They weren’t well documented either, but it was pretty easy to puzzle out the shell scripts that would run, and we all know how to write shell scripts. The systemd way is to use services that are not defined by shell scripts. However, systemd tries to do lots of other things, too. It can replace cron and run things periodically. It can replace inetd, syslog, and many other traditional services. This is a benefit or a drawback, depending on your point of view.
(Editor’s note: And this logging functionality was exactly what was abused in last week’s insane liblzma / ssh backdoor.)
Configuring systemd requires you to create files in one of several locations. In systemd lingo, they are “units.” For the purpose of this Linux Fu, we’ll look at only a few kinds of units: services, mounts, and timers. Services let you run programs in response to something like system start-up. You can require that certain other services are already running or are not running and many other options. If the service dies, you can ask systemd to automatically restart it, or not. Timers can trigger a service at a particular time, much like cron does. Another unit you’ll run into are sockets that represent — you guessed it — a network socket.
Android, the popular mobile phone OS, is essentially just Linux with a nice user interface layer covering it all up. In theory, it should be able to do anything a normal computer running Linux could do. And, since most web servers in the world are running Linux, [PelleMannen] figured his Android phone could run a web server just as well as any other Linux machine and built this webpage that’s currently running on a smartphone, with an additional Reddit post for a little more discussion.
The phone uses Termux (which we’ve written about briefly before) to get to a Bash shell on the Android system. Before that happens, though, some setup needs to take place largely involving installing F-Droid through which Termux can be installed. From there the standard SSH and Apache servers can be installed as if the phone were running a normal Linux The rest of the installation involves tricking the phone into thinking it’s a full-fledged computer including a number of considerations to keep the phone from halting execution when the screen locks and other phone-specific issues.
With everything up and running, [PelleMannen] reports that it runs surprisingly well with the small ARM system outputting almost no heat. Since the project page is being hosted on this phone we can’t guarantee that the link above works, though, and it might get a few too many requests to stay online. We wish it were a little easier to get our pocket-sized computers to behave in similar ways to our regular laptops and PCs (even if they don’t have quite the same amount of power) but if you’re dead-set on repurposing an old phone we’ve also seen them used to great effect in place of a Raspberry Pi.
