Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.

From: Gary Allen Vollink <gary_AT_vollink.com>
Date: Wed, 27 Sep 2017 02:26:55 -0400

Fairly new here, but I have stuff to say.

On the actual subject:

Any massive effort to get root execution across a list of hosts, is
going to be an attractive attack vector. I think it was mentioned,
but a robust key management solution is necessary, at least for ssh,
but likely also for something else, like (p(gp)g). Weighing the
benefits of this with the utility of the need is going to be a
different threshold for different people/organizations. Sudo is NOT a
security program, it is a convenience mechanism. Similarly dropping a
SUID target out there is also a convenience mechanism.

The only way I would trust something like this on my network is if the
payload is signed, by a central authority/user. The signature can be
verified with a public key, and it should be able to verify that the
payload was not altered since the signature was applied. Even better
is if the payload is actually encrypted, but that would require
machine private keys for unencryption (not ideal on edge nodes). Any
other thing that is done to allow escalated run authority should be
carefully written to NOT allow bypass of the signature and must
actively check for cert/key revocations before UID escalation.

This can be as simple as a .signature file delivered with or before
the payload. If it can be guaranteed delivered last, then it can also
act as a semaphore to allow the client to know the transfer is
actually complete, and to not waste cycles trying to verify things
before the transfer is done.

On language:

It seems sufficient to me that as a project, suckless.org is C. Every
project (with the exception of Init scripts) on suckless.org is in C.
It seems that the most active users (owners?) want to keep it that
way, so it seems fruitless to argue about it.

So, a thread about 'go' being cool is probably not going to get
push-back much. The line seems to be where the not-C is suggested as
something that belongs on suckless.org. I think few had an issue when
this thread started out on using 'go' as a proof of concept or
pseudo-code. But the moment it was considered that maybe the PoC
would not be ported to 'C', that is where the line was hit. Maybe I'm
being generous, but what I got out of this thread was in the spirit
of, ~We encourage you to do it, talk about solving the problems, but
it won't be part of suckless.org unless it is in C~.

The obvious requirement for participating in the existing suckless.org
project space is knowing C well enough to keep it succinct and
readable. Adding a new project in not-C is going to have some
chilling effect on existing community members. The desire to learn a
new language really well may not be true for everyone, and for some,
clearly, a not-C project on suckless.org would be seen as being
against what suckless.org stands for. That makes sense to me. This
place is for C. Not-C have many robust communities where such
projects would be welcome.


Thank you,
Gary Allen

On Tue, Sep 26, 2017 at 5:28 PM, Josuah Demangeon <mail_AT_josuah.net> wrote:
>> Other people make different choices than you.
>
>
> That is great.
>
>> Imagine that! Especially if they have other priorities than you.
>
>
> This as well, but I feel large side effects of these choice is being
> hidden to the people that make them: the cost of maintaining
> all of these different languages in a same system.
>
>> P.S.: My stance is that whatever language gets the job done and works
>> for the developers involved is best, and don't let people from outside
>> the project convince you otherwise. I just noticed that all the
>> languages I learned except C don't get the job done for me.
>
>
> I want to stick to C both because I like it (matter of tastes), but
> also because it is the language the system is written in.
>
> If all we had was OS written in Lisps for hardware efficient at
> executing Lisp, I guess I would learn to love Lisp and write
> everything in Lisp for not raising the complexity of the system
> while writing programs...
>
Received on Wed Sep 27 2017 - 08:26:55 CEST