Description of problem: When booting into Fedora16, the GRUB2 menu presents me with 2 options - one to boot the 3.1.0 kernel and the other to boot the 3.1.0 kernel in Recovery mode. If I select the 2nd option (to boot in Recovery Mode), the the system boots and drops me directly into the root account, without even asking for a password! Version-Release number of selected component (if applicable): grub2-1.99-12.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. Switch on the computer. 2. Select "Linux 3.1.0 kernel (Recovery Mode) option in the grub2 menu list 3. System boots into the root account with access to the _entire_ system without so much as a password! Actual results: System boots into the root account with access to the _entire_ system without so much as a password! Expected results: System should ask for the root password before dropping the user into the root recovery shell. Additional info: My hardware profile is posted at http://www.smolts.org/client/show_all/pub_57069a9a-7216-4214-abe4-6a752f54367c
It is true for _any_ non-TPM-architecture that if you have access to the physical machine then you have full access to the machine. You can always boot from an external media and access all unencrypted files - no matter if it is windows, osx or linux. Being able to do the same with boot loader access do thus not reduce the real security of the system much. It is possible to lock up the hardware physically and/or restrict the boot media and protect the bios and lock down the boot loader and lock down the os boot options ... but that is a lot of steps that has to done manually. If you want to lock down the grub configuration or configure boot loader passwords then check the grub documentation. In my opinion it works as designed and as it should and this is no bug.
(In reply to comment #1) > It is true for _any_ non-TPM-architecture that if you have access to the > physical machine then you have full access to the machine. You can always boot > from an external media and access all unencrypted files - no matter if it is > windows, osx or linux. > > Being able to do the same with boot loader access do thus not reduce the real > security of the system much. I understand the logic that a determined hacker/cracker who has physical access to the system will almost certainly gain access to the data within that system, unless it is protected by encryption. However, if one were to follow your logic of reasoning, we should do away with even the login prompt that greets us when we boot into linux on our computers! We have physical access to our computer... so why have a password to login at all??? :-) > It is possible to lock up the hardware physically and/or restrict the boot > media and protect the bios and lock down the boot loader and lock down the os > boot options ... but that is a lot of steps that has to done manually. > > If you want to lock down the grub configuration or configure boot loader > passwords then check the grub documentation. I know that it is possible to lock up the boot loader with passwords, but as you mention, it requires quite a few extra steps. However, a default Fedora 16 installation should have some basic security inbuilt, and having a bootloader option that drops the user into a root shell with access to the _entire_ system, without even asking for the root password, is not a good idea. I would also like to point out that in previous versions of Fedora (upto F15), we did not have a bootloader option of Fedora dropping us into a recovery mode as root, without asking for the root password. > In my opinion it works as designed and as it should and this is no bug. I disagree. Imagine 5 members at a home sharing a Fedora 16 computer. One of the members accidentally chooses the "Recovery mode" from the bootloader prompt while booting, and is dropped into a root shell, without so much as even a password prompt. Think of all the damage that the person can unintentionally do, without even knowing that he is logged in as root? --Vinu.
The grub upstream decision is to let grub2-mkconfig create these recovery entries by default. Anaconda has decided to use grub2-mkconfig, but has decided to not put GRUB_DISABLE_RECOVERY=true /etc/default/grub (though probably not intentionally). So if you want the entries removed then this issue should be re-assigned to anaconda. (Btw: this is set by default in grub2's /etc/default/grub in rawhide ... but will probably be overwritten by anaconda.) (Btw: grubby will not add recovery entries for new kernels but remove them as their kernels are removed, so rescue entries will disappear after some time.) However, this issue could just as well be re-assigned to systemd for not requiring password in single/rescue/runlevel1 mode.
Thank you for the explanation. I guess re-assigning the issue to systemd for not requiring a password in single/rescue/runlevel1 mode would be the best option. I'll do just that.
Single user mode in Fedora is used also for root password recovery thus password is not required by default. This can be secured by admin either with setting password for grub or setting sulogin as shell instead of sushell. Anaconda should set GRUB_DISABLE_RECOVERY=true and don't create recovery mode entry by default.
Did previous Fedora releases require a password when "single" was passed on the boot command line? Do you realize that you will still be able to pass "init=/bin/sh" to bypass any authentication request that systemd might add?
I checked how it traditionally behaved when "single" was passed on the boot line: - RHEL6 (upstart) - by default you are not asked for the password. You can configure it in /etc/sysconfig/init. - RHEL5 (SysVinit) - you are not asked for the password. This is not even configurable. In Fedora with systemd we support the option in /etc/sysconfig/init. Reassigning to Anaconda to consider the "GRUB_DISABLE_RECOVERY=true" option.
The issue as discussed so far is not a security issue. The issue is more like a kind of reverse usability issue: It is too obvious and easy to use the back door that however would be there anyway. If someone wants to "secure" the boot process they have to harden all steps, where this only is one of a handful of places that needs tightening. But ... This become a real security issue if the user configured a boot loader password in anaconda. It is a reasonable expectation that configuring a boot loader password in the OS installer hardens the rest of the boot process and ensures that the bootloader only can boot to the default "runlevel" where unix security applies ... unless the boot loader password is provided. As it is now the password will be a worthless security mechanism in the installed system where the recovery boot option can be used to get root access without any credentials.
No matter what other systems did or do at present, It is common sense that recovery mode MUST ask for the root password before giving root access. I don't understand how there can be an argument on this. > It is true for _any_ non-TPM-architecture that if you have access to the > physical machine then you have full access to the machine. You can always boot > from an external media and access all unencrypted files - no matter if it is > windows, osx or linux. What If I have a BIOS password that does not allow booting from external media? The possibilities are endless. What if my CPU is locked behind a safe and only the keyboard,mouse and monitor are accessible? (I do understand that having physical access means you probably can do anything.) But giving root access without a password validation is a major security vulnerability. Please do not relate this to the boot loader password. The boot loader password is not related to system recovery mode. This bug is related to system recovery mode. I repeat, Giving root access without a password validation is a MAJOR SECURITY VULNERABILITY. Reading the comments above, I do not understand what next action is going to be taken.
Well, I guess the bootloader password comes into it because if you don't set one, it doesn't really matter whether grub shows a system recovery mode or not; someone can always boot to single user mode or with init=/bin/sh and bypass everything with a little typing. And I suppose that if you have the wherewithal to set a bootloader password, you're also capable of sticking GRUB_DISABLE_RECOVERY=true in /etc/default/grub. At least, that's what I do. I still don't understand why that isn't the default but a couple of lines in a kickstart file is easier than arguing about it. I guess that's the way it is with most of the configuration choices I happen to disagree with.
> And I suppose that if you have the wherewithal to set a bootloader password, > you're also capable of sticking GRUB_DISABLE_RECOVERY=true in > /etc/default/grub. The recovery mode is *needed*. Removing the recovery mode option from grub is not the solution. > someone can always boot to single user mode or with init=/bin/sh and bypass > everything with a little typing. That is a different issue. People (say non-technical, newbies) who do not know what init=/bin/sh is can still get root access by a single menu selection and that is a security vulnerability. That fact that specifying init=/bin/sh gives unprotected root access is a total different issue that needs to be addressed independently from this issue. Requiring a bootloader password to boot into system recovery mode will have protection. But the issue is in Fedora recovery mode, It should not depend on grub for passwords.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.