Restrict access to compilers

[monsieuremre]

This can also be implemented as a script pair. lock_compiler and lock_compiler_undo with only root having access to these. Then it might be easier to use compilers without root when needed. But this does not remove functionality anyway. We sould just have to sudo gcc.

[adrelanos]

About sudo gcc, please see: https://github.com/Kicksecure/security-misc/issues/132#issuecomment-1777587637

[monsieuremre]

I see the point. At this time, we can just disable compilers all together. That is of course a real pain for usability especially for devs. Or this can just be an opt-in feature, using a boot parameter or something else.

[adrelanos]

design discussion on how to enable/disable this latest draft and discussion here: https://github.com/Kicksecure/security-misc/issues/132#issuecomment-1783873459

[adrelanos]

As said in the other ticket:

So we don't have to parse on/off for each, best to make a syntax similar to systemctl. Here:

• permission-hardener enable all
• permission-hardener disable all
• permission-hardener enable compiler
• permission-hardener disable compiler
• permission-hardener enable interpreter
• permission-hardener disable interpreter

[adrelanos]

Hmm. To be honest this is no piece of cake to implement.

It's not that difficult.

Currently we got:

• permission-hardener
• permission-hardener-undo

Overloading permission-hardener with the config management would be difficult indeed. So first step would be renaming permission-hardener to permission-hardener-enable or so.

Then the logic of config management could be handled by a new, yet to be invented script.

I might get there one day but not a priority right now.

This is actually extremely simple to implement in a full system apparmor policy. Want to run compilers -> gotta use sudo.

As I said before:

Not great. Better to re-enable compiler access than running compilers with root. Because that leads to follow-up issues. Maybe source code refusing to compile or failing to compile (missing environment variables, different PATH, different user, missing configs/files) and confusing resulting file permissions.

[monsieuremre]

We might be better off just not touching the compilers and recommending users to uninstall them if they don't do development. This enable-disable solution looks a little too much at the users end. This package would be better if it is just a install and forget kind of thing.

[adrelanos]

monsieuremre:

We might be better off just not touching the compilers and recommending users to uninstall them if they don't do development.

This won't work. Sometimes compilers or interpreters are dependencies of other packages.

This enable-disable solution looks a little too much at the users end. This package would be better if it is just a install and forget kind of thing.

Yes. The scope of security-misc still isn't well defined and debatable. Keeping security-misc still useful outside of Kicksecure, Whonix might mandate not disabling compilers/interpreters by default.

However, most of the code could be in security-misc and then other packages could have a config snippet or run a command to enable these protections (compilers lock, interpreter lock).

[monsieuremre]

I don't find this approach to be productive. Hardening as in 'secure by default' should require no further user interaction, let alone forcing them to run commands with options. So for the time being, we can let the compilers be. I'm closing the issue.

[adrelanos]

Compiler lock still planned. Ticket here: https://phabricator.whonix.org/T941

But this will take time.

( Ticket will be migrated to the forums one day. https://forums.whonix.org/t/abolishing-whonix-phabricator-issue-tracker-moving-issue-tracking-to-forums-migrating-phabricator-whonix-org-to-forums-whonix-org/7112 )