[prev in list] [next in list] [prev in thread] [next in thread]
List: grub-devel
Subject: Re: [PATCH] cli_lock: Added build option to block command line interface
From: "Vladimir 'phcoder' Serbinenko" <phcoder () gmail ! com>
Date: 2024-01-26 20:25:38
Message-ID: CAEaD8JNtNNmoDENPTj=WpTiUxmNVGhvh7BYwxLqNWixc0M6GEw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Le ven. 26 janv. 2024, 23:15, Daniel Kiper <dkiper@net-space.pl> a =C3=A9cr=
it :
> On Fri, Jan 26, 2024 at 02:12:31AM +0300, Vladimir 'phcoder' Serbinenko
> wrote:
> > Please detail your use case. GRUB already had user framework in the sam=
e
> > problem space.
>
> I am not sure what exactly you mean by "user framework". Could you
> elaborate or point us code examples?
>
https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-=
authorisation
>
> Anyway, we need a mechanism to disallow access to CLI, arguments editing
> for kernels, etc. I.e. user cannot change widely understood boot config
> even being at the console.
>
Yes and it's exactly what happens as soon as superuser is set. Basically
this patch is equivalent to having a superuser without a valid password.
AFAIR it's achieved by setting superuser's but not issuing password
commands. If not we can have password_deny command.
>
> Daniel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[Attachment #5 (text/html)]
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Le ven. 26 janv. 2024, 23:15, Daniel Kiper <<a \
href="mailto:dkiper@net-space.pl">dkiper@net-space.pl</a>> a écrit \
:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">On Fri, Jan 26, 2024 at 02:12:31AM +0300, Vladimir \
'phcoder' Serbinenko wrote:<br> > Please detail your use case. GRUB \
already had user framework in the same<br> > problem space.<br>
<br>
I am not sure what exactly you mean by "user framework". Could you<br>
elaborate or point us code examples?<br></blockquote></div></div><div \
dir="auto"><br></div><div dir="auto"><a \
href="https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-autho \
risation">https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation</a><br></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Anyway, we need a mechanism to disallow access to CLI, arguments editing<br>
for kernels, etc. I.e. user cannot change widely understood boot config<br>
even being at the console.<br></blockquote></div></div><div dir="auto">Yes and \
it's exactly what happens as soon as superuser is set. Basically this patch is \
equivalent to having a superuser without a valid password. AFAIR it's achieved by \
setting superuser's but not issuing password commands. If not we can have \
password_deny command.</div><div dir="auto"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
Daniel<br>
<br>
_______________________________________________<br>
Grub-devel mailing list<br>
<a href="mailto:Grub-devel@gnu.org" target="_blank" \
rel="noreferrer">Grub-devel@gnu.org</a><br> <a \
href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer noreferrer" \
target="_blank">https://lists.gnu.org/mailman/listinfo/grub-devel</a><br> \
</blockquote></div></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic