Hi again Tito,

On 23/2/20 17:02, Tito via Dng wrote:
> On 2/23/20 4:22 PM, Aitor wrote:
>> Hi Tito,
>>
>> On 23/2/20 14:15, Tito via Dng wrote:
>>> On 2/23/20 1:54 PM, Aitor wrote:
>>>> Hi,
>>>>
>>>> On 23/2/20 13:17, Aitor wrote:
>>>>> The binary won't be suid, but rather it'll receive the root
>>>>> password through the mentioned unix socket using internally (sudo
>>>>> | su) afterwards.
>>>>
>>>> As simple as that:
>>>>
>>>> system( "echo <password> | sudo -S <application_name>");
>>>>
>>>> I tested my first draft and it works. Do it simple, isn't it?
>>>>
>>>> Aitor.
>>>>
>>> Hi,
>>>
>>> this looks dangerous, isn't the password readable unencrypted in
>>> e.g. /proc?
>>> You should never send an unencrypted password over a shell or pipe.
>>> Usually the password as soon as it is inputted is encrypted with the
>>> correct cipher
>>> for the system and the buffer is zeroed, then the encrypted password
>>> is compared
>>> to what is in /etc/shadow or /etc/password or handled in the way is
>>> deemed fit.
>>> I suggest you to handle the passwords and the command and args to be
>>> run in your program
>>> This way:
>>> 1) password stays unencrypted for the shortest time
>>> 2) you have control and you can vet the env, program and args that
>>> are run.
>>>
>>> Hope this helps.
>>>
>>> Ciao,
>>> Tito
>>
>> Thanks for the info, i know... Some people ripped me to shreds in the
>> IRC channel some years ago, when i started working on the backend of
>> simple-netaid.
>>
>> This is only for testing the first part of the project. I have two
>> ideas for the second part:
>>
>> - To have a look at the code of ssh-askpass, suggested by Didier
>> Krin, whose dialog frame is useful only for X11 and not for wayland.
>
> Hi,
>
> i would use a simple gtk window with a gtkentry (Gtk2 GTK3 compatible)
> + 2 buttons (cancel, ok)
> that way it will be the gtk backend to care about X11 or wayland (i
> suppose...):
>
> "put into “password mode” using gtk_entry_set_visibility(). In this
> mode, entered text is displayed using
>  a “invisible” character. By default, GTK+ picks the best invisible
> character that is available in the current
> font, but it can be changed with gtk_entry_set_invisible_char(). Since
> 2.16, GTK+ displays a warning when Caps
> Lock or input methods might interfere with entering text in a password
> entry.
> The warning can be turned off with the “caps-lock-warning” property."
>
> "Note that you probably want to set “input-purpose” to
> GTK_INPUT_PURPOSE_PASSWORD or GTK_INPUT_PURPOSE_PIN
>  to inform input methods about the purpose of this entry, in addition
> to setting visibility to FALSE."
>
> On hitting Enter or the OK button this returns a gchar string (typdef
> of char)
> that could be fed to:
>
>     encrypted = pw_encrypt(plaintext, /*salt:*/ pw_pass, 1);
>     r = (strcmp(encrypted, pw_pass) == 0);
>     free(encrypted);
>     nuke_str(plaintext);
>     return r;
>
> To see a good example take a look at: busybox/libbb/correct_password.c
> This is widely used code and most pitfalls are already handled.

Thanks, i'll have a look at the code. In any case, something like the
code below would be enough:

setenv("SUDO_ASKPASS", password, 1);
printf("%s\n", password);

The password needs to be printed, otherwise it won't work.

Then, sudo reads the value of the system variable via:

askpass = getenv_unhooked("SUDO_ASKPASS");

and inmediately sudo uses the "unsetenv" fuction in ordeer to reset the
value. This is exactly how ssh-askpass works.

All that done, the application can be used in the same way suggested by
Didier, replacing ssh-askpass by our new application.
>
>> - To emulate keypress events in C code afterwards, according to the
>> received password.
>
> Looks as overcomplex to me but I'm not a guru....

Yes, i think so.

>>
>> On the other hand, what do you think about the suid receiving the
>> password through the socket, staying the file descriptor for the
>> shortest time? I assume it encrypted.
>
> Why use 2 binaries rather than one, more programs, more code, more
> communication in between them equals to more attack surface.
> I would stay with just one suid binary, more so if you want to go the
> su-only route.
> After having taken a look at the sudo source code I think it is by far
> more complex than simple su, I personally
> would avoid it at all, but this could be added later after having got
> right the simpler su-only case.
> I will see if I'm able to cobble toghether a working example code just
> for the fun and to refresh
> my C coding skills.

I started using two separate binaries due to the suid permissions.
Bypassing it, then the use of two binaries has no sense.

>
> Just my 2 cents.
>
> Ciao,
> Tito


Thanks a lot!

Aitor.