Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perlless Activation - Tracking Issue #267982

Closed
nikstur opened this issue Nov 16, 2023 · 7 comments · Fixed by #270727
Closed

Perlless Activation - Tracking Issue #267982

nikstur opened this issue Nov 16, 2023 · 7 comments · Fixed by #270727
Labels
significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc.

Comments

@nikstur
Copy link
Contributor

nikstur commented Nov 16, 2023

This is a tracking issue for the perlless activation effort started at OceanSprint.

See this HedgeDoc for a general overview of the strategy for this.

See the Boot Security Meta Tracking Issue for the larger effort of which this work is a part.

Associated PRs:

Bug Fixes:

Please help me review open PRs, if you're passionate about this!

@infinisil infinisil added the significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc. label Nov 19, 2023
@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixpkgs-supply-chain-security-project/34345/8

@asymmetric
Copy link
Contributor

@nikstur I don't know if this is the place to ask, but could you provide more details about the specific ways in which interpreters are an attack surface? The linked document only states that they are, without showing how.

I'm sure you've thought this through, but for the benefits of others who haven't (like me!), I think it would be good to document it.

@nikstur
Copy link
Contributor Author

nikstur commented Nov 22, 2023

@asymmetric that's a good point. I'll expand on my motivation in that document.

@nikstur
Copy link
Contributor Author

nikstur commented Nov 26, 2023

@asymmetric I added some more detail but most importantly a link to the Mitre attack technique T1059 which also lists how this technique has been used in the wild. Hope this helps/is enough to explain why this work is interesting.

@RaitoBezarius
Copy link
Member

RaitoBezarius commented Nov 26, 2023

I will add:

https://lwn.net/Articles/832959/
https://github.com/clipos-archive/clipos4_doc
https://www.youtube.com/watch?v=chNjCRtPKQY&t=1035s

That is, no need for O_MAYEXEC or interpreter cooperation… if you don't have interpreters!

@Atemu Atemu mentioned this issue Nov 27, 2023
13 tasks
@nikstur nikstur mentioned this issue Nov 28, 2023
13 tasks
@ghost
Copy link

ghost commented Nov 30, 2023

@nikstur I don't know if this is the place to ask, but could you provide more details about the specific ways in which interpreters are an attack surface? The linked document only states that they are, without showing how.

I'm interested in the same thing, and I don't feel like the question has really been answered. All the comments in this thread are just link dumps.

most importantly a link to the Mitre attack technique T1059

This is confused... just because Mitre lists something as having been used by BadGuys(tm) does not mean it is a good idea to get rid of it. For example, all of the following are "Mitre attack techniques":

Are we going to remove local accounts, ssh keys, and dns servers from NixOS? SSH keys sure sound a lot scarier when you call them "MITRE Attack Technique T1098". I found these three "attack techniques" by skimming just the first 5% of Mitre's list.

I heard this rumor that hackers even use the ALU in your CPU. Ban all the ALUs! Get rid of the adders! Purge the multipliers! Burn the floating-point unit with fire! 🔥 🔥 🔥

Seriously.

The "all interpreters are bad" is really more of a cultural thing emanating from certain software companies that historically prefer a producer/consumer relationship rather than the collaborative kind of user-as-developer relationship that interpreters (like Nix!) engender. That's fine, that's their preference. But the campaign to spin it as a security matter borders on silliness.

All that being said, less perl in my life would be a great thing. But the problem isn't interpreters, it's just perl.

@nikstur
Copy link
Contributor Author

nikstur commented Nov 30, 2023

Take from it what you will. You don't like Perl, I'm happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants