Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #229299 > unrolled thread

Emergency mode when root account locked

Started bydeandre <d.gopburn10@gmail.com>
First post2020-12-04 13:20 +0100
Last post2020-12-05 15:10 +0100
Articles 11 on this page of 31 — 16 participants

Back to article view | Back to linux.debian.user


Contents

  Emergency mode when root account locked deandre <d.gopburn10@gmail.com> - 2020-12-04 13:20 +0100
    Re: Emergency mode when root account locked Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-04 14:20 +0100
      Re: Emergency mode when root account locked Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-05 11:50 +0100
        Re: Emergency mode when root account locked Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-07 16:20 +0100
          Re: Emergency mode when root account locked Tixy <tixy@yxit.co.uk> - 2020-12-07 16:40 +0100
            Re: Emergency mode when root account locked Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-08 10:00 +0100
              Re: Emergency mode when root account locked Tixy <tixy@yxit.co.uk> - 2020-12-08 10:20 +0100
                Re: Emergency mode when root account locked deloptes <deloptes@gmail.com> - 2020-12-08 12:00 +0100
          Re: Emergency mode when root account locked grumpy@mailfence.com - 2020-12-07 16:40 +0100
            Re: Emergency mode when root account locked Celejar <celejar@gmail.com> - 2020-12-09 01:50 +0100
          Re: Emergency mode when root account locked Fabrice BAUZAC <noon@mykolab.com> - 2020-12-12 01:10 +0100
            Re: Emergency mode when root account locked Keith Bainbridge <ke1thozgroups@gmx.com> - 2020-12-12 03:50 +0100
              Re: Emergency mode when root account locked Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-12 09:40 +0100
                Re: Emergency mode when root account locked Keith Bainbridge <ke1thozgroups@gmx.com> - 2020-12-12 13:00 +0100
                  Re: Emergency mode when root account locked Tixy <tixy@yxit.co.uk> - 2020-12-12 14:10 +0100
                  Re: Emergency mode when root account locked Brian <ad44@cityscape.co.uk> - 2020-12-12 14:10 +0100
                    Re: Emergency mode when root account locked "Andrew M.A. Cater" <amacater@einval.com> - 2020-12-12 14:20 +0100
                      Re: Emergency mode when root account locked Brian <ad44@cityscape.co.uk> - 2020-12-12 14:50 +0100
                      Re: Emergency mode when root account locked Kenneth Parker <sea7kenp@gmail.com> - 2020-12-12 17:40 +0100
                        Re: Emergency mode when root account locked "Andrew M.A. Cater" <amacater@einval.com> - 2020-12-12 18:20 +0100
                          Re: Emergency mode when root account locked Brian <ad44@cityscape.co.uk> - 2020-12-12 18:50 +0100
                  Re: Emergency mode when root account locked Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-12 20:00 +0100
                    Re: Emergency mode when root account locked Brian <ad44@cityscape.co.uk> - 2020-12-12 21:20 +0100
            Re: Emergency mode when root account locked Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-12-12 15:20 +0100
              Re: Emergency mode when root account locked Marco Möller <talby@debianlists.mobilxpress.net> - 2020-12-12 15:40 +0100
                Re: Emergency mode when root account locked Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-12-12 15:50 +0100
              Re: Emergency mode when root account locked deloptes <deloptes@gmail.com> - 2020-12-13 00:50 +0100
          Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-14 12:20 +0100
            Re: Bug#977358: release-notes: document how to make the rescue mode  usable if no root password is set (buster) nickgeovanis <nickgeovanis@gmail.com> - 2020-12-14 13:40 +0100
            Re: Bug#977358: release-notes: document how to make the rescue mode  usable if no root password is set (buster) "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-03-21 09:50 +0100
    Re: Emergency mode when root account locked Marco Möller <talby@debianlists.mobilxpress.net> - 2020-12-05 15:10 +0100

Page 2 of 2 — ← Prev page 1 [2]


#229711

FromBrian <ad44@cityscape.co.uk>
Date2020-12-12 18:50 +0100
Message-ID<BlhbP-4vo-1@gated-at.bofh.it>
In reply to#229710
On Sat 12 Dec 2020 at 17:13:53 +0000, Andrew M.A. Cater wrote:

> On a "normal" as opposed to an Advanced/expert install, it prompts you to give a password for a root user.
> If you effectively tab through this, not setting a password at all, then you
> get a normal user account.

Hardly surprising, given what user-setup-udeb is designed to do.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#229715

FromAndrei POPESCU <andreimpopescu@gmail.com>
Date2020-12-12 20:00 +0100
Message-ID<BlihA-58L-13@gated-at.bofh.it>
In reply to#229695

[Multipart message — attachments visible in raw view] — view raw

On Sb, 12 dec 20, 22:53:41, Keith Bainbridge wrote:
> On 12/12/20 7:29 pm, Andrei POPESCU wrote:
> > > AND run sudo as root, for additional safety
> > Is this supposed to be ironic? I really can't tell.
> 
> 
> There was a detailed discussion here about sudo being a security issue
> on our systems. It appears to be default in debian 10, so most of us get
> it as default. I looked at replacing sudo.
> 
> I found an article that explained how to strengthen it by forcing sudo
> to require root password.
 
To my non-native understanding of English "run foo as root" usually 
means one first gains root privileges (by whatever means) and then runs 
that program with the elevated privileges.

In the context of the text you were replying to it seemed to me you 
might just be ironic (though admittedly I did also consider you might be 
referring to the 'targetpw' option in 'sudoers').

> If somebody breaks in, they now need my root password to execute
> commands that require root permissions (except a couple that I have
> given nopasswd privilege).

If a user's normal account is compromised most of what matters is 
already compromised as well. The root access is just icing on the cake 
and can be easily obtained with a keylogger (which an attacker would 
need anyway for the all the other goodies).

https://xkcd.com/1200/

Otherwise a probably quite simple 'sudo' script[1] in ~/.local/bin 
should do the trick as well: present a password prompt, save the 
password somewhere safe, pretend to fail and then call the real 
'sudo'[3].

After all, how many users are calling 'sudo' with the full path?


Instead I would suggest admin tasks should be performed from a dedicated 
*normal* account, using sudo just for those commands that require 
elevated privileges.

This provides some additional security, while also being slightly safer 
from accidental mistakes than logging in as root directly.


[2] which by default is added to $PATH on Debian.
[1] If I'm bored enough I might just write such a script myself.
[3] and maybe deletes itself to remove traces

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]


#229722

FromBrian <ad44@cityscape.co.uk>
Date2020-12-12 21:20 +0100
Message-ID<BljwZ-63N-1@gated-at.bofh.it>
In reply to#229715
On Sat 12 Dec 2020 at 20:51:26 +0200, Andrei POPESCU wrote:

> On Sb, 12 dec 20, 22:53:41, Keith Bainbridge wrote:
> > On 12/12/20 7:29 pm, Andrei POPESCU wrote:
> > > > AND run sudo as root, for additional safety
> > > Is this supposed to be ironic? I really can't tell.
> > 
> > 
> > There was a detailed discussion here about sudo being a security issue
> > on our systems. It appears to be default in debian 10, so most of us get
> > it as default. I looked at replacing sudo.
> > 
> > I found an article that explained how to strengthen it by forcing sudo
> > to require root password.
>  
> To my non-native understanding of English "run foo as root" usually 
> means one first gains root privileges (by whatever means) and then runs 
> that program with the elevated privileges.

That is my understanding too.

> In the context of the text you were replying to it seemed to me you 
> might just be ironic (though admittedly I did also consider you might be 
> referring to the 'targetpw' option in 'sudoers').

Keith Bainbridge argument begins with a complete misunderstanding of
the role of sudo in the installer. It then mentions an article that
is not referenced. Two fails.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#229702

FromAlex Mestiashvili <amestia@rsh2.donotuse.de>
Date2020-12-12 15:20 +0100
Message-ID<BldUC-2Dv-3@gated-at.bofh.it>
In reply to#229687
Not sure is that was already answered, since I lost track of the thread.
But resetting the root password is just matter of booting with root 
partition it rw mode and init=/bin/bash isn't?


On 12/12/20 1:03 AM, Fabrice BAUZAC wrote:
> Greg Wooledge <wooledg@eeg.ccf.org> writes:
> 
>> Even if you plan to use sudo for 99% of your administrative work,
>> there's still no reason NOT to have a root password, for those emergency
>> situations where you need one.
> 
> I've had the bitter taste of it when I had to salvage a virtual machine
> for which I had lost access to my non-root account.  You'd better have
> the root password around.
> 

[toc] | [prev] | [next] | [standalone]


#229704

FromMarco Möller <talby@debianlists.mobilxpress.net>
Date2020-12-12 15:40 +0100
Message-ID<BledY-2JQ-11@gated-at.bofh.it>
In reply to#229702
On 12.12.20 15:18, Alex Mestiashvili wrote:
> Not sure is that was already answered, since I lost track of the thread.
> But resetting the root password is just matter of booting with root 
> partition it rw mode and init=/bin/bash isn't?

It is not even required to mount your disk from other hardware. Simply 
boot to the grub menu and set this boot parameter:
init=/sbin/sulogin --force

As long as someone has physical access to the Debian carrying disk, you 
can always break into the system! In this case for restoring your access 
options, but of course in other cases this could also be used for evil 
things.
In order to prevent the evil access option you need to activated disk 
encryption. To my knowledge this cannot be bypassed as easily as simply 
gaining root access on an unencrypted system. But of course, if you now 
forget your decryption passphrase, then your system is gone for ever, 
also no more accessible by mounting the disk in another system. If you 
now would have a problem with the root password or sudo setup, you would 
for sure still need the disk decryption passphrase, and only afterwards 
could help yourself with the mentioned boot parameter.
Best wishes, Marco.

[toc] | [prev] | [next] | [standalone]


#229705

FromAlex Mestiashvili <amestia@rsh2.donotuse.de>
Date2020-12-12 15:50 +0100
Message-ID<BlenE-2Nl-13@gated-at.bofh.it>
In reply to#229704

On 12/12/20 3:35 PM, Marco Möller wrote:
> On 12.12.20 15:18, Alex Mestiashvili wrote:
>> Not sure is that was already answered, since I lost track of the thread.
>> But resetting the root password is just matter of booting with root 
>> partition it rw mode and init=/bin/bash isn't?
> 
> It is not even required to mount your disk from other hardware. Simply 
> boot to the grub menu and set this boot parameter:
> init=/sbin/sulogin --force
> 
> As long as someone has physical access to the Debian carrying disk, you 
> can always break into the system! In this case for restoring your access 
> options, but of course in other cases this could also be used for evil 
> things.
> In order to prevent the evil access option you need to activated disk 
> encryption. To my knowledge this cannot be bypassed as easily as simply 
> gaining root access on an unencrypted system. But of course, if you now 
> forget your decryption passphrase, then your system is gone for ever, 
> also no more accessible by mounting the disk in another system. If you 
> now would have a problem with the root password or sudo setup, you would 
> for sure still need the disk decryption passphrase, and only afterwards 
> could help yourself with the mentioned boot parameter.
> Best wishes, Marco.
> 

Hi thanks for the hint, never considered "/sbin/sulogin --force" so far, 
good to know. I normally also set grub password, so one can't edit that 
  easily grub entries. And use full disk encryption for laptops.

Best,
Alex

[toc] | [prev] | [next] | [standalone]


#229727

Fromdeloptes <deloptes@gmail.com>
Date2020-12-13 00:50 +0100
Message-ID<BlmOe-7Wq-5@gated-at.bofh.it>
In reply to#229702
Alex Mestiashvili wrote:

> Not sure is that was already answered, since I lost track of the thread.
> But resetting the root password is just matter of booting with root
> partition it rw mode and init=/bin/bash isn't?

yes, it is - more problematic is the password of the encrypted drive - you
really have to memorize it good, or write it down and lock it in the safe

[toc] | [prev] | [next] | [standalone]


#229748 — Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

FromAndrei POPESCU <andreimpopescu@gmail.com>
Date2020-12-14 12:20 +0100
SubjectBug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)
Message-ID<BlU3v-3pO-5@gated-at.bofh.it>
In reply to#229416

[Multipart message — attachments visible in raw view] — view raw

Package: release-notes
X-Debbugs-CC: debian-user@lists.debian.org

Dear Release Notes Maintainers,

Some text based on below would make sense for the Release Notes for 
buster. If agreed I'll try to come up with a wording.

On Lu, 07 dec 20, 10:11:48, Greg Wooledge wrote:
> On Sat, Dec 05, 2020 at 12:41:57PM +0200, Andrei POPESCU wrote:
> > On Vi, 04 dec 20, 08:09:44, Greg Wooledge wrote:
> > > I am also going to guess that Deepin, like Ubuntu, defaults to giving
> > > you a user account with sudo access, and no root password.  You can
> > > achieve that in Debian as well, by doing something special during the
> > > installation.  In all cases, it's a stupid idea and you shouldn't do it.
> > 
> > This is a pretty strong (and harsh!) statement. Care to expand on the 
> > reasons?
> 
> It prevents access to single-user mode.  The fact that Debian (and
> these others?) still puts a single-user mode entry into the GRUB menu,
> knowing that it won't work, is just adding insult to injury.

A web search found #802211[1].

Short version:

For systemd >= 240 (buster[2]) run as root

    systemctl edit rescue.service
    
and add:

    [Service]
    Environment=SYSTEMD_SULOGIN_FORCE=1

(see /usr/share/doc/systemd/ENVIRONMENT.md.gz)


The 'rescue.service' is started by systemd in case it detects 'single' 
on the kernel command line (see systemd(1)).

You might want to do the same for 'emergency.service' as well (or 
instead), since this service is started *automatically* in case of 
certain errors (see systemd.special(7)) or if you add 'emergency' to the 
kernel command line (e.g. if you can't fix your system via the 'rescue' 
service).


An untested patch to the Debian Installer exists to add both snippets if 
the user chooses to leave the root password blank.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
[2] see the bug for another snippet that should work for squeeze or 
earlier.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]


#229750 — Re: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

Fromnickgeovanis <nickgeovanis@gmail.com>
Date2020-12-14 13:40 +0100
SubjectRe: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)
Message-ID<BlViW-463-11@gated-at.bofh.it>
In reply to#229748

[Multipart message — attachments visible in raw view] — view raw

Thanks Andrei.

On Mon, Dec 14, 2020, 5:15 AM Andrei POPESCU <andreimpopescu@gmail.com>
wrote:

> Package: release-notes
> X-Debbugs-CC: debian-user@lists.debian.org
>
> Dear Release Notes Maintainers,
>
> Some text based on below would make sense for the Release Notes for
> buster. If agreed I'll try to come up with a wording.
>
> On Lu, 07 dec 20, 10:11:48, Greg Wooledge wrote:
> > On Sat, Dec 05, 2020 at 12:41:57PM +0200, Andrei POPESCU wrote:
> > > On Vi, 04 dec 20, 08:09:44, Greg Wooledge wrote:
> > > > I am also going to guess that Deepin, like Ubuntu, defaults to giving
> > > > you a user account with sudo access, and no root password.  You can
> > > > achieve that in Debian as well, by doing something special during the
> > > > installation.  In all cases, it's a stupid idea and you shouldn't do
> it.
> > >
> > > This is a pretty strong (and harsh!) statement. Care to expand on the
> > > reasons?
> >
> > It prevents access to single-user mode.  The fact that Debian (and
> > these others?) still puts a single-user mode entry into the GRUB menu,
> > knowing that it won't work, is just adding insult to injury.
>
> A web search found #802211[1].
>
> Short version:
>
> For systemd >= 240 (buster[2]) run as root
>
>     systemctl edit rescue.service
>
> and add:
>
>     [Service]
>     Environment=SYSTEMD_SULOGIN_FORCE=1
>
> (see /usr/share/doc/systemd/ENVIRONMENT.md.gz)
>
>
> The 'rescue.service' is started by systemd in case it detects 'single'
> on the kernel command line (see systemd(1)).
>
> You might want to do the same for 'emergency.service' as well (or
> instead), since this service is started *automatically* in case of
> certain errors (see systemd.special(7)) or if you add 'emergency' to the
> kernel command line (e.g. if you can't fix your system via the 'rescue'
> service).
>
>
> An untested patch to the Debian Installer exists to add both snippets if
> the user chooses to leave the root password blank.
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
> [2] see the bug for another snippet that should work for squeeze or
> earlier.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

[toc] | [prev] | [next] | [standalone]


#233273 — Re: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

From"Alexander V. Makartsev" <avbetev@gmail.com>
Date2021-03-21 09:50 +0100
SubjectRe: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)
Message-ID<BV1Wy-3y8-11@gated-at.bofh.it>
In reply to#229748

[Multipart message — attachments visible in raw view] — view raw

On 21.03.2021 12:40, Andrei POPESCU wrote:
> [Bcc: debian-boot]
>
> Dear Debian-User subscribers,
>
> The Release Notes editor is asking whether this is still an issue for
> bullseye (i.e. if the patch to Debian Installer mentioned below was
> applied in the meantime).
>
> It will be a while until I get to check that. If someone can confirm
> either way please write to #977358.
>
> Full quote below for context.
>
> Thanks,
> Andrei
>
This is still an issue for bullseye. Patch was not applied, but solution 
works if you apply it manually after OS installation.
I've tested it on latest weekly build (debian-testing-amd64-netinst.iso).

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]


#229348

FromMarco Möller <talby@debianlists.mobilxpress.net>
Date2020-12-05 15:10 +0100
Message-ID<BiGq5-51U-1@gated-at.bofh.it>
In reply to#229299
On 04.12.20 13:00, deandre wrote:
> Hi
> 
> My problem is when I try to boot up deepin(Debian 10 buster) I get the 
> message “cannot open access to console, the root account is locked See 
> sulogin(8) man for more details” and after I press Enter it continues to 
> give me the same message, at this point I’m not really sure what to do.
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 

If the root account login is deactivated, then the rescue console 
(rescue.target or emergency.target) usually cannot be entered.
However, in the grub menu it can still be forced the launch o a shell as 
root, even if the root account was deactivated, by adding the following 
boot parameter:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
init=/sbin/sulogin --force
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Best wishes,
Marco.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user


csiph-web