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