single-user mode on pi + debian wheezy?

[washe]

Is there a way of booting into single-user mode? Or disabling init.d startup scripts during boot? I've installed a hastily-written script on a Pi running Debian Wheezy which is stopping me getting to the login prompt. Alternatively... is it easy to mount an SD card on a USB reader, I can fix it that way.

any ideas appreciated!

thanks

[jecxjo]

Probably the easiest way is to edit cmdline.txt and add the following parameter

Code: Select all

init=/bin/sh

This tells the kernel that once its loaded instead of running /sbin/init as usual you should run /bin/sh. You will get a shell with no services configured, just straight from kernel to shell. This can be done on any computer with a SD card reader as you are only modifying a file in the /boot partition (Fat32). Very simple.

Your userid will be 0 so you will have root permissions, just none of the initd scripts have run. This means you can change passwords, undo modifications that broke your system, etc.

[washe]

that's great, I got my pi back! thanks

[electronicsguy]

is there a way to disable this?

[buja]

How about removing "init=/bin/sh" from cmdline.txt?
(basically undoing what the second post in this topic suggested)

[electronicsguy]

How about removing "init=/bin/sh" from cmdline.txt?
(basically undoing what the second post in this topic suggested)

Haha I know that. What I meant is: is it possible to disable single user mode so someone cannot gain access this way.

[DougieLawson]

How about removing "init=/bin/sh" from cmdline.txt?
(basically undoing what the second post in this topic suggested)

Haha I know that. What I meant is: is it possible to disable single user mode so someone cannot gain access this way.

No. If I can pull your SDCard and update it in another system I can break in to your Raspberry Pi and you CAN NOT stop me.

Lock the RPi in a cage, fix the SDCard in the RPi with a hot glue gun.

[electronicsguy]

Thanks Dougie. Is there a reason why linux keeps this single user logon? Since you're from a systems background I'm guessing you know a lot about this. Yes I know, if someone has physical access to a machine, they can do whatever they want with the data. But this just seems to make it easier for them, isn't it?

[DougieLawson]

The RPi is unique, you can easily pull the primary data storage device without opening the case. On a secure system you'd a) keep the machine in a secure room, b) not let anyone loose on hardware and c) have a hard drive controller that trashes the data if any tampering occurs.

Remember these things came from the 1960s and 1970s when computers were kept in sealed rooms and "ordinary" users fed their data in on cards, tape or paper tape and came back the next day for the printout when their job had run.

[electronicsguy]

The RPi is unique, you can easily pull the primary data storage device without opening the case. On a secure system you'd a) keep the machine in a secure room, b) not let anyone loose on hardware and c) have a hard drive controller that trashes the data if any tampering occurs.

Remember these things came from the 1960s and 1970s when computers were kept in sealed rooms and "ordinary" users fed their data in on cards, tape or paper tape and came back the next day for the printout when their job had run.

I understand. My curiosity is: why continue having this in the modern linux architecture. Will a large segment of users be affected if single user mode is disabled today?

[rpdom]

I understand. My curiosity is: why continue having this in the modern linux architecture. Will a large segment of users be affected if single user mode is disabled today?

Is there any reason to disable it? Most proper servers are still kept in a secure (or fairly secure) environment. Single user mode is still useful (I use it on a regular basis on one system) for some administration work.

Oh and i have to disagree with:

The RPi is unique, you can easily pull the primary data storage device without opening the case.

because of the number of systems that I have worked with that had drives that could be just pulled out (ok, not when they were running, but you wouldn't normally get away with doing that on a Pi either) and put in another machine to hack settings - if you had physical access to them.

[electronicsguy]

I understand. My curiosity is: why continue having this in the modern linux architecture. Will a large segment of users be affected if single user mode is disabled today?

Is there any reason to disable it? Most proper servers are still kept in a secure (or fairly secure) environment. Single user mode is still useful (I use it on a regular basis on one system) for some administration work.

Oh and i have to disagree with:

The RPi is unique, you can easily pull the primary data storage device without opening the case.

because of the number of systems that I have worked with that had drives that could be just pulled out (ok, not when they were running, but you wouldn't normally get away with doing that on a Pi either) and put in another machine to hack settings - if you had physical access to them.

Well if its useful, those sys admins can enable it right? Why have it enabled by default?

[DougieLawson]

It isn't enabled by default, you have to update cmdline.txt to change the init= parm that's passed to the kernel. You need some form of physical security to prevent unauthorised changes to kernel parameters.

[electronicsguy]

It isn't enabled by default, you have to update cmdline.txt to change the init= parm that's passed to the kernel. You need some form of physical security to prevent unauthorised changes to kernel parameters.

Sorry that's not what I meant. I meant the ability to use this particular kernel parameter is enabled by default, even if you have to make the manual change to the kernel parameters.

At some point in the kernel code, the kernel looks at these parameters and runs the shell with root privileges instead of init correct? What exactly would break if those lines of code in the kernel were to be commented out?

[DougieLawson]

Being able to override the init program is essential. The fact that you can use init=/bin/sh to breach security is an unfortunate side-effect.

It's the least of your problems if you're trying to harden a RPi.

[electronicsguy]

Being able to override the init program is essential. The fact that you can use init=/bin/sh to breach security is an unfortunate side-effect.

It's the least of your problems if you're trying to harden a RPi.

thanks no i am not really trying to harden my system right now, just trying to understand the philosophy behind the design.

Now, who exactly is init override beneficial for? If we were to write the linux kernel today, would be still have the option to override it ON by default?
If the benefits are for a large segment of people, noobs and high-end IT sysads included, then it makes sense to continue having it.

If its only beneficial to a small group of people, is it impossible for them to uncomment out those lines and re-compile the kernel for their use? I am assuming that these people can do that, and probably do compile their own kernels all the time for many reasons correct?

btw: for someone wanting to improve security and make it harder to break in, I found this write-up:
http://www.tecmint.com/how-to-hack-your ... ux-system/

[DougieLawson]

The trouble is that it's a lifeline, it's the thing you use when the filesystem needs to be fsck'd to recover the system. When you have a system that you can't install a new kernel on but you need it back in a hurry.

The RPF kernel also has the magic SysReq key enabled. You'll probably consider that as another thing you'd like to remove.

It's not ideal, but that's the design for how the kernel passes control to process id #1 which is the first program to run in userland rather than as a kernel driver/module.

[electronicsguy]

The trouble is that it's a lifeline, it's the thing you use when the filesystem needs to be fsck'd to recover the system. When you have a system that you can't install a new kernel on but you need it back in a hurry.

The RPF kernel also has the magic SysReq key enabled. You'll probably consider that as another thing you'd like to remove.

It's not ideal, but that's the design for how the kernel passes control to process id #1 which is the first program to run in userland rather than as a kernel driver/module.

Thanks again for the explanation. I still don't see why someone like me would need it and why someone like you couldn't have it by compiling your own kernel but I guess that's the way it is.

AFAIK, for screwed up partitions/disks, I can fsck by installing it in another machine and we don't need root password of the target disk to fsck it. So IMHO, that part is redundant, unless you want to run fsck on that machine itself, without removing the disk. Which is also possible, by booting through a USB stick containing system rescue cd?

[ghans]

The Pi can only boot from SD cards initially. The rootfs might be an USB harddrive , but you still need the SD card for bootup.

ghans

[electronicsguy]

The Pi can only boot from SD cards initially. The rootfs might be an USB harddrive , but you still need the SD card for bootup.

ghans

Ya, so? I don't think this has anything to do with boot time security.

[ghans]

The recovery kernel needs already to be on the SD card if
the Pi is my only Linux machine.


ghans

[electronicsguy]

again, so what? btw, it can be on an USB stick too.

[ragnarjensen]

Now, who exactly is init override beneficial for?

In my case, the 2.3 million users of the system I oversee. If it goes belly-up, I need to be able to fix it double-quick.

If we were to write the linux kernel today, would be still have the option to override it ON by default?

I sincerely hope so.

If the benefits are for a large segment of people, noobs and high-end IT sysads included, then it makes sense to continue having it.

I'm glad you've seen the light

If its only beneficial to a small group of people, is it impossible for them to uncomment out those lines and re-compile the kernel for their use? I am assuming that these people can do that, and probably do compile their own kernels all the time for many reasons correct?

In the corporate world, when you buy a complete system, it's fairly common that you're not allowed to touch the OS.
"Oh, you rolled your own kernel? Sorry, then you're not running our distribution any more. Your support contract is now null and void."

The trouble is that it's a lifeline, it's the thing you use when the filesystem needs to be fsck'd to recover the system. When you have a system that you can't install a new kernel on but you need it back in a hurry."

Very true. And sometimes it's the other way around. More than once, I have faced the situation where the disks were healthy but the computer itself had died. I plugged the disks into very dissimilar hardware and thanks to single-user mode I was able to reconfigure the systems, to make them able to go multiuser at all on the new hardware.

Being able to boot to single-user is not a security problem in itself. If I can lay my hands on your console, you have no security.
--
Ragnar

[electronicsguy]

All points taken. and thanks for highlighting the business side scenarios, of which I have little knowledge.

but at the end of the day, the 'Raspbian' is not a business oriented OS, bound by contracts where you cannot modify the OS. If it is a customized OS designed from Debian by the foundation, why can't we have this implemented as far as Raspbian is concerned. For all business folks bound by contracts, there's always red-hat.

Let me put it this way - what specific purpose is being served by having the capability to modify kernel parameters already baked in, in the Raspbian distro, for its users?

Yes you could lay my hands on my console and get all the data. But AFAIU, isn't it making it easier for you to lay your hands on my Pi, when you may not have your own computer to insert the sd-card into? If this is false, then I rest my case.

[ragnarjensen]

All points taken. and thanks for highlighting the business side scenarios, of which I have little knowledge.

You're welcome

For all business folks bound by contracts, there's always red-hat.

"Oh, you rolled your own kernel? Sorry, then you're not running our distribution any more. Your support contract is now null and void."
That is a real quote from a RedHat representative...

Let me put it this way - what specific purpose is being served by having the capability to modify kernel parameters already baked in, in the Raspbian distro, for its users?

The first post in this thread is an excellent example. A simple mistake made the system inaccessible to its owner. Single-user mode made it easy to get control back.

Yes you could lay my hands on my console and get all the data. But AFAIU, isn't it making it easier for you to lay your hands on my Pi, when you may not have your own computer to insert the sd-card into?

Yes, it makes it easier, but not by much, there are other ways in. The SysReq key that Dougie mentions is one. If I'm only after your data and not looking to take control of your computer, I don't need to bring a computer of my own, I'll just steal the SD card and look at it at my leisure afterwards. Or, seeing that your computer is a tiny Pi that fits in my pocket, I'll steal that too
--
Ragnar