Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #229299 > unrolled thread
| Started by | deandre <d.gopburn10@gmail.com> |
|---|---|
| First post | 2020-12-04 13:20 +0100 |
| Last post | 2020-12-05 15:10 +0100 |
| Articles | 11 on this page of 31 — 16 participants |
Back to article view | Back to linux.debian.user
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]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2020-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]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-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]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2020-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]
| From | Alex Mestiashvili <amestia@rsh2.donotuse.de> |
|---|---|
| Date | 2020-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]
| From | Marco Möller <talby@debianlists.mobilxpress.net> |
|---|---|
| Date | 2020-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]
| From | Alex Mestiashvili <amestia@rsh2.donotuse.de> |
|---|---|
| Date | 2020-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]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2020-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]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-12-14 12:20 +0100 |
| Subject | Bug#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]
| From | nickgeovanis <nickgeovanis@gmail.com> |
|---|---|
| Date | 2020-12-14 13:40 +0100 |
| Subject | Re: 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]
| From | "Alexander V. Makartsev" <avbetev@gmail.com> |
|---|---|
| Date | 2021-03-21 09:50 +0100 |
| Subject | Re: 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]
| From | Marco Möller <talby@debianlists.mobilxpress.net> |
|---|---|
| Date | 2020-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