I messed up my system earlier, I was greeted with a black screen, when booting in to Ubuntu. When I started up my laptop, I selected the recovery option from the grub menu, and chose fallback at root terminal. I saw that I was able to use the add user command, with it, I probably could use to create a privileged user on my machine.

Isn't that a security issue?

One could have stolen my laptop and at startup chose recovery and add another user, I'm fudged then. Including my data.

Come to think of it, even if you somehow remove that entry, one could boot from a live-CD, get a chroot up and running and then add another user, with the right privileges that allows it to see all my data.

If I set the BIOS to boot at my HD only, no USB, CD/DVD, Network startup, and set a BIOS password, it still wouldn't matter, because you'd still have that grub recovery startup entry.

I am fairly certain that someone from China, Russia can't hack my Ubuntu Trusty Tahr, from the network, because it's secure like that. But, if one has physical access to my - your - machine, then, well, that's why I'm asking this question. How can I secure my machine so that hacking through physical access is not possible?

Bug Report:

  • 35
    Full disk encryption and glitternailpolish for your screws. Who does not do that nowadays? – mondjunge Sep 21 '15 at 8:19
  • 2
    @ByteCommander you can add root users. Just add another user with uid 0 to /etc/password. I just added fred fred:x:0:0:fred,,,:/home/fred:/bin/bash and now if I login as fred and run whoami, I get root – Josef Sep 21 '15 at 9:05
  • 3
    @ByteCommander they should be. The tools to manage accounts like adduser etc. won't let you do that usually, but just editing /etc/passwd works. Being a hacker means ignoring what you should do ;) – Josef Sep 21 '15 at 9:10
  • 3
    @blade19899 Your new bug will surely be declined. Compare this existing one: bugs.launchpad.net/ubuntu/+bug/283662 – Byte Commander Sep 21 '15 at 9:33
  • 4
    @blade19899 My broader point is that you need to think in terms of risks and trade-offs, not absolutes. I have no idea who you are or where you live but a house robbery leading to someone effectively using your data (instead of just trying to off-load the hardware) sill sounds a bit far fetched and possibly less of a concern than the time, money or even data loss that could result from the lack of effective recovery options. Which is why having a fall-back root terminal is a good thing. But obviously that's not to say that you shouldn't look into full-disk encryption. – Relaxed Sep 22 '15 at 10:01

My guess is that only full disk encryption using a strong algorithm and, most important, good password is the only thing that can secure your locally stored data. This gives you probably 99.99% security. Please refer to one of the many guides on how to do this.

Besides than that, it is NOT possible to secure your machine from an experienced hacker with physical access.

  • User/account passwords:
    It's easy to create a new admin user if you boot into recovery mode, as you described yourself, because you get a root shell without being asked for passwords this way.
    That might look like an accidental security issue, but is intended for (who would have thought that?) recovery cases, where you e.g. lost your admin password or messed up the sudo command or other vital stuff.

  • root password:
    Ubuntu has not set any root user password by default. However, you can set one and will be asked for it if you boot in recovery mode. This seems pretty secure, but is still no ultimately secure solution. You can still add the kernel parameter single init=/bin/bashthrough GRUB before booting Ubuntu that starts it in single user mode - which is in fact a root shell without password too.

  • Securing the GRUB menu with a password:
    You can secure your GRUB menu entries to be only accessible after authentication, i.e. you can deny booting the recovery mode without password. This also prevents from manipulating the kernel parameters. For more information, refer see the Grub2/Passwords site on help.ubuntu.com. This can only be bypassed if you boot from an external medium or connect the HDD to another machine directly.

  • Disable booting from external media in BIOS:
    You can set the boot order and usually exclude devices from boot in many current BIOS/UEFI versions. Those settings are not secured though, as everybody can enter the setup menu. You have to set a password here too, but...

  • BIOS passwords:
    You can usually bypass BIOS passwords as well. There are several methods:

    • Reset CMOS memory (where BIOS settings are stored) by opening the computer case and physically removing the CMOS battery or temporarily setting a "Clear CMOS" jumper.
    • Reset BIOS settings with a service key combination. Most motherboard manufacturers describe key combinations in their service manuals to reset messed up BIOS settings to default values, including the password. An example would be to hold ScreenUp while turning on the power, which, if I remember right, unlocked an acer motherboard with AMI BIOS once for me after I messed up my overclocking settings.
    • Last but not least, there are a set of default BIOS passwords that seem to always work, independent of the real set password. I did not test it, but this site offers a list of them, categorized by manufacturer.
      Thanks to Rinzwind for this information and link!
  • Lock the computer case/deny physical access to the motherboard and hard disk:
    Even if everything else fails, a data thief can still open your laptop/computer, take the HDD out and connect it to his own computer. Mounting it and accessing all unencrypted files is a piece of cake from thereon. You have to put it into a securely locked case where you can be sure nobody is able to open the computer. This however is impossible for laptops and difficult for desktops. Maybe you can think of owning an action film like self-destructing device that blows up some explosives inside if somebody tries to open it? ;-) But make sure you'll never have to open it yourself for maintenance then!

  • Full disk encryption:
    I know I advised this method as secure, but it also is not 100% safe if you lose your laptop while it is on. There is a so-called "cold boot attack" that allows the attacker to read the encryption keys from your RAM after resetting the running machine. This unloads the system, but does not flush the RAM contents of the time without power is short enough.
    Thanks to kos for his comment about this attack!
    I'm also going to quote his second comment here:

    This is an old video, but explains the concept well: "Lest We Remember: Cold Boot Attacks on Encryption Keys" on YouTube; if you have a BIOS password set, the attacker can still remove the CMOS battery while the laptop is still on to enable the custom crafted drive to boot without losing any crucial second; this is scarier nowadays due to SSDs, as a custom crafted SSD will probably be capable to dump even 8GB in less than 1 minute, considering a write speed of ~150MB/s

    Related, but still unanswered question on how to prevent Cold Boot Attacks: How do I enable Ubuntu (using full disk encryption) to call LUKSsupend before sleeping/suspending to RAM?

To conclude: Currently nothing really protects your laptop from getting used by someone with physical access and malicious intent. You can only fully encrypt all your data if you're paranoid enough to risk losing everything by forgetting your password or a crash. So encryption makes backups even more important than they're already are. However, they should then be encrypted too and located in a very safe place.
Or just don't give your laptop away and hope you'll never lose it. ;-)

If you care less about your data but more about your hardware, you might want to buy and install a GPS sender into your case though, but that is only for the real paranoid people or federal agents.

  • 7
    And still full disk encryption wouldn't save you from cold-boot attacks, if your laptop is stolen while is on! – kos Sep 21 '15 at 8:50
  • 14
    Also after your laptop was outside your control for any amount of time, it can't be expected to be safe anymore. It could now log your pre-boot password, for example. – Josef Sep 21 '15 at 9:00
  • 1
    Encrypting your data shouldn't increase the risk to lose it, because you do have backups, right? Data only stored once is not much better than data not existing. SSDs especially tend to suddenly fail without a chance to get anything out of them. – Josef Sep 21 '15 at 9:15
  • 3
    This is an old video, but explains the concept well: youtube.com/watch?v=JDaicPIgn9U; if you have a BIOS password set, the attacker can still remove the CMOS battery while the laptop is still on to enable the custom crafted drive to boot without losing any crucial second; this is scarier nowadays due to SSDs, as a custom crafted SSD will probably be capable to dump even 8GB in less than 1 minute, considering a write speed of ~150MB/s – kos Sep 21 '15 at 9:22
  • 2
    @ByteCommander but your SSD can fail just the same and all your data is lost. Sure, if you tend to forget passwords (well, write it down and put it in your safe then) the likelihood of losing all your data might increase with encryption, but it is not like your data is super safe unless you dare to encrypt it. You don't "risk everything by forgetting your password or a crash", you do that by not having backups. – Josef Sep 21 '15 at 9:28

The most secure laptop is the one without any data on it. You could set up your own private cloud environment and then don't store anything of importance locally.

Or take out the hard drive and melt it down with thermite. While this technically answers the question, it might not be the most practical since you won't be able to use your laptop anymore. But neither will those ever-nebulous hackers.

Barring those options, dual-encrypt the hard drive and require a USB thumbdrive to be plugged in to decrypt it. The USB thumbdrive contains one set of decryption keys and the BIOS contains the other set - password protected, of course. Combine that with an automatic data self-destruct routine if the USB thumbdrive is not plugged in during boot/resume from suspend. Carry the USB thumbdrive on your person at all times. This combination also happens to deal with XKCD #538.

XKCD #538

  • 7
    Automatic self-destruct routine will certainly be a pleasant surprise once your USB thumbdrive accumulates some dust on the contact pads. – Dmitry Grigoryev Sep 22 '15 at 9:29

Encrypt your disk. This way your system and your data will be safe in case your laptop is stolen. Otherwise:

  • BIOS password won't help: the thief can easily extract the disk from your computer and put it on another PC to boot from it.
  • Your user/root password won't help either: the thief can easily mount the disk as explained above and access all your data.

I would recommend you to have a LUKS partition in which you could set up a LVM. You could leave your boot partition unencrypted so that you only need to enter your password once. This means your system could be more easily compromised if tampered (stolen and given back to you without you even noticing), but this is a very rare case and, unless you think you are being followed by the NSA, a government or some kind of mafia, you should not be worried about this.

Your Ubuntu installer should give you the option of installing with LUKS+LVM in a very easy and automated way. I am not re-posting the details in here, as there is already plenty of documentation out there on the internet. :-)

  • If possible, could you provide a more detailed answer. As you can tell by my question I'm not a security buff. – blade19899 Sep 21 '15 at 7:56
  • upvoted for the bullet points, but note that full-disk encryption is not the only way, nor is it necessary if you confine your sensitive files to /home/yourName - as you should! - then stack this folder with a file-level encryption driver (such as one I mentioned at the OP and won't spam again), a very viable alternative. I'm not worried about people seeing all the boring stuff in /usr, etc. – underscore_d Sep 23 '15 at 23:27
  • 1
    @underscore_d: I am indeed worried about other stuff outside /home (including personal and professional data in other partitions), so it's easier for me to encrypt everything, but I guess each user has their own needs :-). However, using ecryptfs is not the best performance-wise decision. You can find some benchmarks here. Be sure to read pages 2-5 in the article for actual results (page 1 is just an introduction). – Peque Sep 24 '15 at 7:24
  • Very true, thanks for the link/benchmarks. I've not hit any performance barriers yet, but maybe later I will. Also, I realised I'll probably have to start thinking about encrypting stuff like /var/log, /var/www (source), & /tmp, so maybe full-disk encryption will start to seem more sensible! – underscore_d Sep 24 '15 at 9:41
  • @underscore_d: yeah, and then you start thinking about /etc and other top-level directories... At the end full disk encryption is a simple and fast solution that will let you sleep like a baby every night. ^^ – Peque Sep 24 '15 at 9:52

There are a couple of hardware solutions worth noting.

Firstly some laptops, such as some Lenovo business laptops come with a tamper detection switch which detects when the case is opened. On Lenovo this feature needs to be activated in BIOS and an admin password needs to be set. If tamper is detected the laptop will (I believe) immediately shut down, on startup it will then display a warning and require the admin password and the proper AC adapter to proceed. Some tamper detectors will also set off an audible alarm, and can be configured to send an e-mail.

Tamper detection doesn't really prevent tampering (but it may make it harder to steal data from the RAM - and tamper detection may "brick" the device if it detects something really dodgy like trying to remove the CMOS battery). The main advantage is that someone can't covertly tamper with the hardware without you knowing - if you have set up strong software security such as full disk encryption then covert tampering with hardware is definitely one of the remaining attack vectors.

Another physical security is that some laptops can be locked to a dock. If the dock is securely mounted to a table (via screws which will be under the laptop) and the laptop kept locked to the dock when not in use, then it provides an additional layer of physical protection. Of course this wont stop a determined thief but it definitely makes it harder to steal the laptop from your home or business, and while locked it's still perfectly usable (and you can plug in peripherals, ethernet and so on to the dock).

Of course, these physical features aren't useful for securing a laptop which doesn't have them. But if you are security conscious it may be worthwhile considering them when buying a laptop.


Additionally to encrypting your disk (you won't get around that): - SELinux and TRESOR. Both harden the Linux kernel and try to make it difficult for attackers to read things from memory.

While you are at it: We now enter the territory of not only fear of evil random guys wanting your debit card info (they don't do that) but often enough of intelligence agencies. In that case you want to do more:

  • Try to purge evrything closed-source (also firmware) from the PC. This includes UEFI/BIOS !
  • Use tianocore/coreboot as new UEFI/BIOS
  • Use SecureBoot with your own keys.

There are plenty of other things you can do but those should give a reasonable amount of things they need to tickle with.

And don't forget about: xkcd ;-)

  • These suggestions are not helpful. Neither SELinux nor TRESOR stops someone with physical access. They're not designed for this threat model. They will provide a false sense of security. P.S. Purging closed-source code is completely unrelated to providing security against someone with physical access. – D.W. Sep 21 '15 at 18:39
  • 1
    @D.W. "TRESOR (recursive acronym for "TRESOR Runs Encryption Securely Outside RAM") is a Linux kernel patch which provides CPU-only based encryption to defend against cold boot attacks" - so TRESOR definitely does help in such scenarios. But that's just a side point. I wrote 'Additionally' as those things won't really do anything if you do not encrypt your disk (in a physical-access scenario). However when you bump up physical security you should not forget that the attacker still can just boot up and do a digital attack, too (ie. exploiting bugs). – larkey Sep 21 '15 at 20:12
  • @D.W. It's pretty shitty if your PC is nicely encrypted but is prone to privilege escalation. That's why - if one is about to secure the system from a physical side - one should also do some hardening software-side. I explicitly stated that they hardened the Linux Kernel and they should be done additionally. The same thing goes for closed-source software. Your disk might be nicely encrypted but if there's a back-door keylogger in the UEFI it won't help you against intelligence agencies. – larkey Sep 21 '15 at 20:14
  • If you use full disk encryption and don't leave your computer running unattended, privilege escalation attacks are irrelevant, as the attacker won't know the decryption password. (Proper use of full disk encryption requires you to shut down/hibernate when unattended.) If you use full disk encryption and do leave your computer unattended, then full disk encryption can be bypassed by any number of methods -- e.g., attaching a USB dongle -- even if you use TRESOR, SELinux, etc. Again, those aren't designed for this threat model. This answer doesn't seem to reflect a careful security analysis. – D.W. Sep 21 '15 at 20:27
  • 1
    With the weasel-wording "try to", anything qualifies -- rot13 encryption can try to ensure that an exploit cannot take over the system. It won't succeed worth a darn, but I can describe it as trying. My point is that the defenses you are singling out are not effective at stopping this class of attacks. SELinux/TRESOR don't stop cold boot. To analyze security, you have to start with a threat model and analyze defenses against that specific threat model. Security is not the process of sprinkling on an endless list of additional restrictions that sound good. There is some science to it. – D.W. Sep 21 '15 at 23:58

Because you changed the question a bit, here is my answer to the changed part:

How can I secure my machine so that hacking through physical access is not possible?

Answer: You can't

There are lots of advanced hardware and software systems like tamper detection, encryption etc, but it all comes to this:

You can protect your data, but you can't protect your hardware once someone had access to it. And if you continue to use any hardware after someone else had access, you are endangering your data!

Use a secure notebook with tamper detection that clears the RAM when someone tries to open it, use full-disk encryption, store backups of your data encrypted in different locations. Then make it as hard as possible to get physical access to your hardware. But if you believe someone had access to your hardware, wipe it and throw it away.

The next question you should ask is: How can I acquire new hardware that hasn't been tampered with.


Use an ATA password for your HDD/SSD

This will prevent the use of the disk without the password. This means you can't boot without the password because you can't access the MBR or the ESP without the password. And if the disk is used inside another manchine, the password is still required.

So, you can use a so-called user ATA password for your HDD/SSD. This is usually set inside the BIOS (but this is not a BIOS password).

For extra security, you can set a master ATA password on the disk too. To disable the use of the manufacturer password.

You can do this on the cli with hdparm too.

Extra care should be taken because you can loose all your data if you loose the password.


Note: There is also weaknesses here as there are softwares that claim to recover the ATA password, or even claim to remove it. So it's not 100% safe either.

Note: ATA password does not necessarily come with FED (Full Disk Encryption)

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.