Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 8, 2021 at 6:10 PM Björn Persson <Bjorn@rombobjörn.se> wrote:
>
> Chris Adams wrote:
> > Once upon a time, Björn Persson <Bjorn@rombobjörn.se> said:
> > > Chris Adams wrote:
> > > > If the admin has done one thing to lock down the system, then they can
> > > > do another (removing the sulogin --force addition).
> > >
> > > How do you propose to ensure that the admin is made aware of the need
> > > to do that?
> >
> > The same way as any change - documentation.
>
> Introducing a new security hole is not just a change like any other
> change.
>
> Sysadmins read documentation to find solutions when they know that they
> have a problem to solve. They rarely read documentation to look for
> problems they don't know about, and they don't regularly re-read every
> document to look for potentially insecure changes.
>
> > > Experienced sysadmins won't just instinctively know that in this new
> > > release of this particular distribution they need to run this special
> > > command to prevent boot problems from granting root access to whoever
> > > can type on the keyboard.
> >
> > It's not a "special command", it's just removing an RPM
>
> Po-tay-to, po-tah-to.
>
> > I don't install a brand new OS and give it to users without checking it
> > out myself
>
> Does "checking it out" include breaking the system in every way you can
> think of, to see whether one of them yields a root shell?
>
> > (and reading at least the release notes).
>
> Do you also read the release notes of all previous releases just in
> case an obscure weakness was introduced in an old release that you
> never used, and has been in place since then?
>
> > This is NOT some new "hole" - out of the box, Fedora already allows
> > someone with console access to get root access (in less convenient, but
> > more confusing, ways).
>
> What you're actually saying is: There is an old hole that we hope
> sysadmins are aware of and know how to close if they need to, and
> therefore it's fine to punch another hole in a hidden place where
> sysadmins won't think to look.

Sorry, but this one is a tiny brick at the entrance into
a gigantic dark scary hole called 'physical access',
which usually just trips someone up.

Yes, I can imagine a convoluted specifically constructed scenario
where it can play the pivotal role in the security of the overall system.
Meaning, yes, if you manually build the entire missing wall around it,
yanking it out would be bad for you, sure.
That still doesn't deter me from arguing this is a bad default
worth flipping with all the fanfare we can get about it.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux