thejh

It is not really security theater if you consider all the other systems they have in place: the clearance process, auditing, etc.

What I see is a use of RBAC that is not all that stupid, and that I happen to use on my own systems. RBAC is being used not to guard against abuse but to guard against mistakes. I use the SELinux sandbox to run my web browser, because it is easy to make a mistake like this:

http://thejh.net/misc/website-terminal-copy-paste

Ah, not so fast, the sandbox keeps that mistake from spreading all over my home directory. Now, the NSA has people who deal with important national security matters (or whatever), but they might make mistakes too. So the NSA uses RBAC to ensure that an analyst cannot accidentally copy and paste some intelligence secrets into a document that will be sent to people without clearance. Remember that the NSA does not just hire random people off the street; there is some amount of filtering meant to reduce the number of insider threats, but that process alone does not necessarily protect against honest mistakes (hence RBAC).

It may also be the case that the NSA is not trying to guard against abuses by sysadmins, but by the tens of thousands of non-sysadmins they employ. In theory this is silly because it just means that your enemies will try to get their agents to work as sysadmins, but in practice it is likely to be a cost-effective solution that greatly reduces the number of people you need to worry about.

Finally there…

One thing not addressed is that copy-pasting from the browser is insecure too:

http://thejh.net/misc/website-terminal-copy-paste

But this should be mitigated by TLS/finding a "trusted" source. A bigger issue might be that curl|bash effectively elevates trust in the developer, the CA, the hosting provider to the same level as trust in your distribution's security team.

And while using SSL, wrapping the script in a function, practising safe posix shell, working acrosss many platforms is good - is it better than using something like https://0install.net ?

I can understand not wanting to work with dozens of distributions; but if you don' tautomate tests across all of those - does your fantastic script really work?

[Ed: it's also much easier to secure an off-line signing key than a TLS key that must be always on-line]

A few terminals, despite having Bracketed Paste Mode, are vulnerable to escape injection. That's when the end-paste escape sequence is included in the paste content, and the terminal lets it pass through, causing the shell to think the paste ended.

Urxvt is one such terminal with that vulnerability, but it can be fixed with a small perl extension, like the one I provided here:

https://security.stackexchange.com/questions/39118/how-can-i-protect-myself-from-this-kind-of-clipboard-abuse/184112#184112

That answer also includes a table checking other terminals for that vulnerability.

The second example on the following page can be used to test a terminal for that variation of the attack:

https://thejh.net/misc/website-terminal-copy-paste

This is bizarre. Why not just give users link to the source?

https://sorting.cr.yp.to/djbsort-20180710.tar.gz

And it's certainly not about good security practices:

* The page teaches users to paste stuff copied from web into a terminal, whereas many terminals are still vulnerable to this: https://thejh.net/misc/website-terminal-copy-paste

* The page teaches users to use su to lower privileges, whereas many (most?) su implementations are vulnerable to tty hijacking.

Even if browsers didn't allow changing the clipboard, there's still this older problem: http://thejh.net/misc/website-terminal-copy-paste

The solution is definitely to avoid pasting commands with newlines in them into your terminal. With Vim, you can use the + register to paste (e.g. "+p). Using iTerm on OS X, I've added a custom keymap for Cmd+V, bound to Run coprocess:

pbpaste | tr -d "\n"

which filters out the newlines.