Please don't use AppArmor for plugin security
-
@chrishamm In https://github.com/Duet3D/DuetSoftwareFramework/issues/103 you mentioned the use of AppArmor for the plugin interface. Please don't do that. The use of AppArmor will eliminate the possibility of running DSF on other distros and I can't imagine why you'd need a sledgehammer like AppArmor (or Selinux) for a fairly closed environment. There as to be a better/easier way.
-
@gtj0 We are trying to convince the Raspi kernel team to add optional AppArmor support to the standard 32-bit Linux kernel. It can be already enabled in the 64-bit kernel without rebuilding it so we hope this change will make it into the stock kernel fairly soon.
We will need to enforce certain security limitations for third-party plugins and AppArmor is a suitable option because it is a lightweight security module compared to SELinux. With AppArmor we can define permissions per app while leaving DAC in charge for everything else. So I don't see why you claim this would be something like a sledgehammer.
SELinux is certainly no option because it enforces MAC everywhere, which is definitely not the case with AppArmor.
-
@gtj0 which distro will AppArmour not work with?
We are not trying to make it impossible to use DSF w/o AppArmour, the idea is that 3rd party plugins to DSF should be limited in what they can do.
-
I said "sledgehammer" because both AppArmor and SELinux implement kernel level MAC. No RedHat distros (Fedora, CentOS) support AppArmor. It's not built into their shipped kernels nor are there packages for it so you'd have to compile your own kernel and build your own packages. On the other hand, SELinux is supported by all distros. Don't get me wrong, I'm not suggesting SELinux. I'm wondering just what are you trying to prevent plugins from doing and isn't there a cross-platform/distro way of doing it?
Oh, if you planning to make the use of AppArmor optional, then that's fine as long as there are no library requirements, etc that can't be turned off at build time.
-
@gtj0 if we are going to allow third party plugins to be installed by users then we want a way to prevent them from having any access that the user does not explicitly grant.
This is part of a range of measures that will make it less likely for malicious plugins to cause issues.
-
@T3P3Tony Access to what though? System services and data? Specific printer capabilities?
Is there a plugin architecture doc somewhere yet?
What framework are plugins expected to be implemented in? Python? Compiled C? .NET assemblies? etc.
How are plugins expected to be distributed?
How are plugins going to be sandboxed?
How do they communicate with the rest of the DSF?
Are the plugins going to be running in their own processes?
Can the generic Linux Capabilities facility be used? -
@gtj0 The following set of permissions has been defined for the first beta but will be likely extended and/or changed: Different DSF capabilities, read/write access to the individual (virtual) SD card directories, generic file system access, ability to launch new processes, stand-alone network access, running certain things as super-user. The preliminary plugin manifest can be found here but again this is work in progress.
In general, plugins will be installable from the web interface as a ZIP bundle and they may contain files for DWC, RRF, or executables (+ other resources) to be executed on the SBC. Plugin management on the SBC may be done either via DWC or using a new cli tool that I wrote for this purpose. Plugins may be written in JS for the web interface and in .NET (Core), Python, or Go. Any application supporting JSON objects should in principle be able to communicate with DSF, though.
Certain DWC plugins will be installable in stand-alone operation (i.e. without SBC), too.
Please let's discuss further details about the plugin interface when 3.2-b1 is out - this is definitely the wrong thread. A documentation about this is coming soon, too.
-
@chrishamm OK, no problem. In the mean time, I'll go through the latest DSF commits and checkout what's already there.
