AppArmour! (Security)

[QJKX]

AppArmour sounds like a good thing to be supporting on Linux.

AppArmor proactively protects the operating system and
applications from external or internal threats, even zero-day attacks,
by enforcing good behavior and preventing even unknown application
flaws from being exploited. AppArmor security policies completely
define what system resources individual applications can access,
and with what privileges. A number of default policies are included
with AppArmor, and using a combination of advanced static analysis
and learning-based tools, AppArmor policies for even very complex
applications can be deployed successfully in a matter of hours.

Opinions? Is it the best tool for the job? Alternatives for other OSes?
I think a jamulus AppArmour profile would live in the AppArmour repository, not here.

[pljones]

It would be down to the server administrator installing a Jamulus server to define the system resources, as these can all be set (and many require setting to activate). Similarly for the client.

Perhaps this is something that needs a more coherent explanation of what input can be given in common, rather than per case.

[QJKX]

Not sure I understand?
A profile should improve security by default, by forbidding Jamulus from doing things it doesn't need to do anyway.
By not trusting Jamulus any more than necessary, we have some peace of mind from the inevitable software bugs that happen in any vaguely sophisticated program. This is particularly relevant to Jamulus because it has custom network code (handling UDP) and uses languages that might not provide memory safety.

The basic rules would be

• forbid Jamulus from reading files it doesn't need to see - so it can't steal your browser passwords.
• forbid Jamulus from writing files it doesn't need to - so a backdoor can't be installed into a user's .profile. Also a bug can no longer cause data-loss.

None of this requires any changes to Jamulus - it just goes in a policy definition.

[rdica]

Ubuntu is linux, but linux isn't Ubuntu. Your solution is specific to Ubuntu. and from what you describe above, for client configurations.
A server won't by default have a GUI, and thus no web browser.
As a server, what files does Jamulus read besides supporting libraries and sockets? Only ones specifically configured, like welcome messages, server status, none of which are enabled by default. The same applies for files written by Jamulus, none by default, all have to be specifically configured.

The Ubuntu user should decide whether to implement any apparmor policy, especially when it impacts behaviour, like where files are written when recording. Increased support calls that aren't about Jamulus specifically would be the result in a forced policy installation.

I could see offering a policy, outside the deb installation of Jamulus, with documentation detailing the default behaviour, and how to alter it for site specific configurations.

Would you also offer to write policies for the other linux security frameworks, for those that don't use Ubuntu?

[QJKX]

Your solution is specific to Ubuntu.

Debian actually - which covers a significant chunk of Linux based systems including Raspberry Pi OS (but it might need to be actually enabled).

like where files are written when recording

A very good point.

I could see offering a policy, outside the deb installation of Jamulus, with documentation detailing the default behaviour, and how to alter it for site specific configurations.

I think that's how it works anyway.

Would you also offer to write policies for the other linux security frameworks, for those that don't use Ubuntu

For now, no.