Tool for virtual networks

Mon Jul 18 15:48:10 UTC 2022

> Believe being the operative word. Maybe you are right, maybe not,
> presenting it as factual truth is dishonest and potentially harmful.
>
> My general rule of thumb, satisfy legal, regulatory and customer
> contract requirements for infosec and other than that, largely ignore
> policies which are only justifiable by infosec. Of course in many
> cases doing things the right way, happens to align with the infosec
> community desires and has 0 infosec cost, while having some perceived
> infosec gains, and that is fine.
>

Is it an accurate representation of your position here that NOT allowing
any user in the sudo group access to run any command they want is somehow
'security theater' then?

On Sat, Jul 16, 2022 at 3:04 AM Saku Ytti <saku at ytti.fi> wrote:

> On Fri, 15 Jul 2022 at 21:57, Grant Taylor via NANOG <nanog at nanog.org>
> wrote:
>
> > Have you ever walked away from your terminal without locking it?  Or
> > seen anyone else do it?
>
> Probably, and probably also after I've already sudoed regardless of
> authentication. And of course a retrospective look from any point to
> history shows us various trivial local privilege escalation bugs which
> have existed for 5-10-15-20 years, i.e. various trivial local
> privilege escalation bugs exist now for anyone with hobbyist interest
> finding them.
> Devices which have a large commercial motive to keep safe and the
> vendor owns the whole vertical and thus are easy to build securely,
> are regularly owned by hobbyists just for fun. If there is a
> commercial motive, you are being pwned regardless of your sudo policy.
> Realised risks for big companies appear to be extremely cheap, based
> on publicly disclosed  issues and their impact on market
> capitalization. Cost of protection must be significantly lower than
> realised risk.
> Attacker has massive financial leverage, I don't have context to say
> anything actually useful, but I believe the leverage is easily 1k, and
> could be much more than 1M. That is, every dollar my adversary spends
> attacking, I must spend 1000 dollars protecting, to successfully stop
> them.
> We have many obvious problems in tooling, like using C, which we
> pretend are user errors 'git good', which if we decided to fix, could
> significantly reduce attack surface, but we don't, no one cares about
> infosec.
>
> > There are also concerns of changing effective users on systems to one
> > that has the NOPASSWD: option, thereby enabling the original user to do
> > what the new user could do without authenticating as the new user.
>
> I can accept concerns, and people are very much free to interpret
> their security posture as they wish. But offering objective truths
> from opinions is not appropriate.
>
> It is very easy to paint various risk scenarios, but without
> substantiating what is the cost of preventing the risk and what is the
> cost of realised risk, it is just horoscope. One thing you can achieve
> easily in infosec, is decreased productivity due to making things
> slower or reducing motivation by forcing people to use workflow they
> are not accustomed to.
> This model causes escalation of dubious policies which never needed to
> be substantiated. Maybe some help, maybe not, but at least they
> increase cost.
>
> Various models of working are valid, you could have root only, and you
> could use ssh certificate signing for certificates which are valid for
> minutes.
>
> > I don't believe avoiding NOPASSWD: is just a horoscope.
>
> Believe being the operative word. Maybe you are right, maybe not,
> presenting it as factual truth is dishonest and potentially harmful.
>
> My general rule of thumb, satisfy legal, regulatory and customer
> contract requirements for infosec and other than that, largely ignore
> policies which are only justifiable by infosec. Of course in many
> cases doing things the right way, happens to align with the infosec
> community desires and has 0 infosec cost, while having some perceived
> infosec gains, and that is fine.
>
> --
>   ++ytti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220718/d1c939bf/attachment.html>