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

2017-09-26 Thread Markus Wichmann
On Sun, Sep 24, 2017 at 11:08:23PM -0400, Rendov Norra wrote:
> The archive shows silence and positivity on threads with go in the subject. 
> Unfortunately gmane is unusable, so there's no way to search bodies.

I guess everyone here is just too jaded to respond to those threads
anymore. Anytime someone posts something that is not in C, the core
posters in this ML get their panties in a twist and demand a rewrite.
Going so far as to call C++ an insidious infection that is slowly
spreading. Oh, the horror! Other people make different choices than you.
Imagine that! Especially if they have other priorities than you.

These threads always converge after finitely many steps to a discussion
about programming languages, which are as useful as discussions about
religion, and just as toxic. So these days, whenever someone comments on
programming languages, I just up the strategic popcorn reserves and
await the show.

Ciao,
Markus

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.



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

2017-09-26 Thread Josuah Demangeon

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...



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

2017-09-26 Thread Gary Allen Vollink
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  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...
>