If you have physical access to a Linux machine, you can boot into live session from USB and you are root. Then you edit /etc/passwd and /etc/shadow and other files on disk.

That's one reason why people use full-disk encryption, to defeat this kind of attack. If you don't know the disk decryption password, you can't read or change the data on disk, the worst you can do is overwrite the disk and make it unbootable/unreadable.

1 members found this post helpful.

Oh, it’s even worse than you think…

Not many people know this, but if know where to look you can find the entire source code of Linux on the Internet!

I wish I were joking, but I am not. The entire source code of Linux can be found by anyone with a very little amount of research (I found it; I won’t tell where it was, but it was disturbingly easy to find). And then anyone can find the security holes and start exploiting them!

Of course when I found that I immediately wiped out Slackware from my machine and replaced it with a good old Windows XP SP2 (I knew it was a good idea not to throw that CD away!).

1 members found this post helpful.

But it does allow you to change the system's root password. I thought that was the point?

Not news at all... that's the way it is meant to be.
But then I guess you tried trolling everyone here

@gouttegd: OP does not deserve to have the thread derailed like this.

Alright, alright.

So, OP: You may have been genuinely well-intentioned in reporting this, but the fact is you found nothing new, and nothing that “Linux Professionals” should be alerted about.

It’s a well-known and well-accepted truth that once bad guys have physical access to your machine, all bets are off. Booting on another system than the one installed on the hard disk (using e.g. a USB key, or, back in the old days, on a live-CD, or, back in the even older days, on a floppy disk), mounting the root filesystem, and doing whatever you want on it (including messing with /etc/shadow). It has been completely documented for decades – as it should be, because it’s a perfectly legitimate way of doing exactly what you wanted to do: restoring access to your system after you forgot your password.

It is not a security vulnerability and it says nothing about the “safety of a Linux-computer”.

If you are still concerned about what you found, there are ways to protect your system even in the case your machine gets in the physical hands of an attacker. By order of simplicity and depending on the kind of attacks you want to protect yourself against:

BIOS passwords
Will prevent an attacker from booting on anything, including a live USB/CD.

What it will not protect against: data theft. If what the attackers are looking for is your data on your disk, then all they have to do is to physically open your machine, take the hard disk out, and put it into another machine. Then they can boot on that other machine and explore the contents of the disk as much as they want.

Full-disk encryption
Will prevent an attacker from doing what I just wrote: even if they put the disk in another machine, they won’t be able to mount the filesystem and explore its contents without knowing the encryption passphrase. They can try brute-forcing the passphrase of course, but as long as you chose a “decent” passphrase you should have nothing to worry about.

What it will not protect against: the so-called “evil maid attacks”. Basically, a scenario when the attackers get physical access to your machine once, alter the boot system, then somehow give you your machine back in such a way that you do not realize it has been in their hands and has been tampered with (for example, a hotel maid could do that by entering your room while you’re having breakfast at the hotel’s restaurant – hence the nickname of this kind of attacks).

SecureBoot
Implemented correctly and assuming you trust Microsoft, it should prevent the ”evil maid attacks”, by preventing the attackers from tampering with the boot system (or rather, they may still tamper with the boot system, but after that SecureBoot should prevent it from booting).

2 members found this post helpful.

Then, even if your discovery actually is as significant as you seem to think it is, you're not actually reporting anything. What makes you think that a thread where you go out of your way to withhold information would be interesting to "Linux professionals"?

In the open source community, we do not believe in security by obscurity.

BTW, I'm sorry you did not like the word "trivial", but you'd better believe that "I got myself locked out and I figured out how to get back in without googling; here's how I did it" would have been a more impressive story of what actually happened.

@bert07: you seem to have missed that question, and I think it is important information. Thanks.

What you told is just nonsense. In most cases you cannot go to the host (especially if that was a virtual server).
You can always try to hack a physical server, but usually you are not allowed to reach them. So those hosts are not in danger (from this point of view).
From the other hand some hosts contain encrypted volumes, so you will not be able to alter the system (but you can destroy it).
BIOS password was also mentioned, you cannot even boot anything without knowing that.

So it is not true, linux systems are not really vulnerable that way. There are other problems which must be taken more seriously.

For all the "pooh-pooh" about it, SecureBoot™ was developed to address a legitimate business concern. That, during "regularly scheduled downtime," corporate spies would secretly "reboot" a server under another operating system (Linux ...), and thereby entirely(!!) bypass the corporation's intended (Windows based ... or could indeed be Linux based ...) security controls.

The situation at the time was basically: "an impregnable(?) bank-vault door beside an open window."

While the implementation chosen, of course, was "the result of many technical compromises," it more-or-less did achieve the minimal intended outcome. And, it could be implemented within the very-limited constraints of "BIOS firmware programming" on most then-existing hardware. The necessary new programming could be applied using a routine "flash update" which wouldn't "brick" the computer in question.

Today, it has actually worked. You can no longer expect to be able to reboot a server "into anything you want," just by sticking a USB-stick into a slot on the front panel and pressing the "reset" button. Without being challenged, and stopped.

Of course, legitimate Linux installations were never denied proper access to the necessary PKI-key information, because Linux today is a perfectly-legitimate part of the picture which requires just as much protection.

"No, it isn't great, but more-or-less it does work ..."

Except that none of the OEMs have keys signed by Linux projects. The various distros, led down the path by Canonical, have their shims and such signed by M$. If the distros' own keys were distributed by the UEFI / Restricted Boot cabal, then it would be less risky than it has become. As it stands, the distros require M$ permission to boot, if Restricted Boot is turned on.

Genuinely curious as to what bert07 thinks you’re actually supposed to do if you forget your login passwords.

So far as I am aware, Microsoft is the custodian of the private key. I don't know if there are others.

While the essence of this thread's topic and discussion is rather lofty for one of my marginal skills, the aspect I did pick up on is forgetting a password, especially for a seldom used notebook or back-up rig:

Construct a password that's an amalgam of a machine's model number and motherboard designation.

And yes, though it too can be bypassed, a UEFI / BIOS password will add time to a ne'er-do-well's effort, thereby increasing the risk of his being exposed.

In the case of a notebook computer, said UEFI / BIOS password can form a significant obstacle to realizing a worthwhile profit for those who'd be better off learning how to use a laptop instead of stealing one.

$0.02

From my Tutorial, How to enter Single-User Mode on FreeBSD from the boot screen: