Replies: 2 comments 2 replies
-
yes, apparmor was designed to do this, it just hasn't been fully opened up yet. the above video covers the pledge/unveil mimicking, and abilities similar to landlock. It doesn't cover where the user can be admin of their own profiles that can be stacked with and coexist with system policy, nor does it cover system interfaces that allow users to extend system policy (both snapd permission prompting, and aa-notify are doing this but there will be more around this in the future). but apparmor will also work with landlock and seccomp as well.
this can be, and is already done for some applications. There are a few advantages, and a few problems with this.
When it works it really nice, when it doesn't it becomes a really head ache. Generally after internal discussions, the decision to keep most profiles packaged separately.
Maybe for some, certainly not for others. A lot of upstreams just don't care and will configure profiles to get out of the way instead of actually be useful, see docker, and cups as an example. Canonical/Ubuntu have been working on making it so the profiles are triggered as part of the autopackage tests, its not necessarily the upstream CI, but has resulted in some rather big updates for apparmor.d
experience says otherwise, and I don't think apparmor is ready for it quite yet, at least not without some dedicated resources behind it. I can tell Canonical now has 4 devs working full time, and the majority the work time is just trying to address bugs/issues, instead of actual dev. Also I don't think policy is adaptive enough yet. There is work to be done to fix some issues. What are the issues
Ubuntu is currently at a point that it will only provide apparmor.d via ppa because there are just too many issue for the package to even be considered for universe. This isn't a knock on apparmor.d its just a reality of having a lot of policy, and being able to make it available to users in a reasonable manner. Call it a core apparmor issue. There is a lot of work being done here.
I am sure I have missed something, there are a lot of moving pieces atm. But basically a large policy like apparmor.d is considered unacceptable by distros until some of the problems around user, memory use, and load times are resolved
Honestly, I don't think this is going to happen. There will always be devs who don't want or don't care to deal with profiles. Experience has also taught that having to run all over the place to grab different profiles to do analysis and integration testing is not good. Upstream apparmor we have been going the other direction, we want all profiles upstream, we want to be able to sync to and from other projects if they have profiles, so we can see how the their profile differs, but also so we can feed bugs/and patches back to the projects carrying profiles. Having all the profiles, and variants in one place, just makes it easier for a lot of things we want to do policy wise, especially you get to larger policy sets that have a lot of profile interactions to map and analyse for security purposes.
yes, some can but we also want to be careful with it so that apparmor policy isn't a burden for them. I think generally we have some more work to do on building out the reference set in a way that upstreams don't have to do a lot of work to support a bunch of different distros and config options.
well apparmor.d or parts of it are going to merge into upstream apparmor, @roddhjav will be involved and apparmor.d will become a smaller diff against the upstream set. There are a couple of other things coming to help with this, the big one is overlay support. So that policy can live in multiple directories and a file in one dir can override or cause whiteouts in another. eg. you could do something like /etc/apparmor.d/:/var/lib/apparmor.d/profiles:/var/lib/apparmor/profiles/ where
well it will still need extensive testing but we could certainly do with less maintenance. The maintenance load is extremely high atm.
yes, its a general problem with any mac type system. Especially those that are using ambient capabilities
this is true to a point. There will always be a trade off between usability and security. You can't have things like confidentiality of user data without involving the user in the decision of what can be shared. Over all the goal is to be low touch, and not bother the user unless needed. Hence things like portals that provide transparent ways of getting user input. But even on android, and ios you get prompted for some decisions. AppArmor has been very much working towards this. We have work to integrate with portals, and if we can't to try and be transparent in other ways. There is work to make user decisions, not affect other user policy, to be more adaptive and dynamic, allowing for tighter policy overall, at the same time as bothering the user less. |
Beta Was this translation helpful? Give feedback.
-
That seems to be an interesting approach indeed, but its also not quite what I had in mind. This is still one of the best explanations on the topic: https://www.youtube.com/watch?v=2e91cEzq3Us
The statement about a required trade off between usability and security is quite common but something I strongly disagree with! It isnt easy to accomplish but there are plenty examples of how good security can be entirely invisible for the user without any trade off whatsoever and it seems to me those examples are also the most effective solutions with real life impact. OpenSSH being one of the most commonly cited example, as are browser sandboxes. Nobody who did not read the code or documentation on these applications would even be aware of the heavy use of privilege separation and sandboxing because it does not get in the users way. That is what I see as the paradim to aim for in apparmor as well. If the profiles of applications are maintained by the upstream developers themselves, there is a good chance they are complete, much more so then when we try to maintain 1500 application profiles that we did not write outselves. |
Beta Was this translation helpful? Give feedback.
-
Both points are true for the application priv sep apparmor is doing in the presentation. In fact it goes so far as to emulate BSD's pledge/unveil on linux.
Yes lots can be done, but the reality is that there are always trade-offs, the application developer can do many things to improve the security posture without bothering the user, but there are several things especially when we start talking confidentiality that may need user input, or not be within the bounds application developer envisions. Android/iOS decisions around side loading are security/user trade-offs. Not allowing side loading is more secure, but then its also vendor lock in, and taking choice away from the user. Another choice is around whether to allow running unsigned code, similar to vendor controlled side loading but allowing for a org/user key and signing. Another around what interpreters/scripting engines to allow. Another around admins, and roles. Are you a high security facility, do you need your systems air gapped, do you need MLS read down/write up properties to ensure secrecy/confidentiality. What of the user who decides they don't trust an application, and decides they want to control access to data beyond what the application dev decides. I can tell you apps do so pretty surprising things even when they are priv sep. Basically there are different layers of security and each one may have different goals. There are vendor and level goals, admin level, user level, and application level. Priv sep in the application is one layer, it doesn't really take into account what the admin, or the user desires. Simple decisions like do you want to allow access to the camera, are a point of friction, there are certainly better ways to handle it, and the app being coded correctly to use system priv sep for such permissions goes a long way towards reducing the security/usability trade-off. I just don't see it ever going away completely.
sure priv sep is great, but again the ssh as a general application needs broad user file access for all its different uses. You can scope it down some by passing options, but in general that is trusting the user to get those right. That is a user friction point between the application priv sep and security. And if the user or admin wants to restrict ssh beyond what its priv sep can do, that has the potential to be another friction point.
I wish that was true. Experience has taught me most application devs/maintainers don't want security interfering with their application/users, they are fine with keeping a general broad bounds covering everything (and usually more) that their application can do, but accommodating more is often beyond what they are willing to do. We have several examples of devs, who effectively make the profiles they maintained equivalent to unconfined.
maybe, but there are some pretty different approaches, and there are technical limitations that can be very hard to accommodate between one model and another. Take something as simple as apparmor's emulation of pledge/unveil it will never be perfect for several reasons. Partly because pledge/unveil isn't a spec, its a dejour standard that evolves and is being tweaked. Partly because it relies on BSD behaviors, and Linux has some differences, or applications compiled for Linux behave different on Linux than when compiled for BSD, and partly because how apparmor does some things; some of these are limitations of the LSM and we would have to get the upstream kernel to accept changes (that may or may not happen). Seccomp, has baked into it races around accessing data passed to the syscall via pointer. Flatpak assumes a permisive object (fd) delegation model, bubblejail as well assumes a permission object (fd) delegation model. Both flatpak and bubbl jail assume user namespaces and capabilities within the user namespace should be allowed, ideally only during the setup, but sadly not true for all applications. Firefox, and chrome sandboxes rely on user namespaces, and capabilities within the namespace, and a permissive object (fd) delegation model. SELinux is an ambient capabilities model that requires correct pre labeling on objects, AppArmor is a ambient capabilities model with controlled (not permissive) delegation. That is to say each system has its quirks and design and implementation trade-offs. Finding a common manifest will be a challenge and likely result in something unsatisfactory. But that isn't to say that its a challenge that shouldn't be tried. |
Beta Was this translation helpful? Give feedback.
-
What I meant was to apply the principle of creating the confinement policy by the upstream developer regardless of the availability of pledge/unveil within the application. The interpretation of pledge would add another aspect that is independant of that.
I think I get your point that is essentially saying that different threat models require additional confinements like MLS in addition to simple prvilege separation. That may be true and apparmor should certainly make this possible even with the idea of upstream profiles and privilege speration in place. My point is however that the linux ecosystem needs a better approach to a default security paradigm that aligns with the general purpose operating system that most linux distributions are providing. To achieve that, the primary objective would be to enforce effective security boundaries by default that use the process layer and ideally in process privilege separation to create such a boundary to a similar effect then the sandbox system on android. While additional confinements may be wanted and implemented in some cases, the use of mechanisms as implemented in the examples like openssh provide exactly this effective security boundary without any trade of. At least I am not aware of any restrictions on ssh or modern browsers that would get in the users way. Nor do I know of configuration options in these applications that are commonly used to remove restrictions to allow additional use cases. Apparmor is unfortunately different with questions like how to disable it being way too prominent in search engines. Therefore I think that apparmor should strive for a similar paradim of confinement without getting in the users way and contrary to your statement, Im convinced it is possible because it is already the case for many existing profiles. And with that it will already provide a boundary that requires additional steps for attackers to overcome, similar to how mobile OS and browsers now require expensive exploit chains for successful compromise. At the moment, desltop linux is trivial to exploit with a single vulnerability and that would be to change with apparmor deployed alongside upstream packages. The primary issue I see for that approach is the isolation of gui applications beacuse as you rightly pointed out, these include many user choices like what files to access. The xdg-portals may be the best way to solve this and if we can have a good integration of those with apparmor, that may solve most of the issues without changing profiles. As I understand it however, the xdg-portals require the applications itself to first adopt the API, which is outside our control. Another issue is that some services like wayland require either the application itself to setup a security contet, or rely on a middleware like flatpak to do so. See #802 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/275 which I would love to hear your thougths on. One major issue I would like to see the apparmor project avoid is to push security decisions to the user. The flatpak project is a good example of this and I consider it to be an epic security nightmare. While it does more then sandboxing, it is used by many for that reason and going through the profiles available on flathub, I hardly find any without trivial sandbox escape. Even worse, the idea of leaving security relevant decisions to end users through tools like flatseal seems insane to me. Based on the average online advice on flatpak isolation, there arent many who are aware of even the most fundamental issues. For example many Linux users are aware of the weakness in the X11 server, but most discussions mention the weakness that allow to evesdrop on the input of other X11 windows, while the possibility of input injection is rarely cited, yet it allows trivial sandbox escape and for anyone who has things like root shells in xterm, it means trivial and direct privilege escalation to root. The idea of leaving such decisions to end users is fundamentally broken and I am convinced there should not be any gui tools to allow easy configuration of any security related settings, because nobody who isn't comfortable with managing profile rules on the terminal doenst have a realistic chance of being qualified to change those rules safely anyway. And ...
.. as you pointed out, many developers aren't qualified or interested either, but at least they know the requirements of their applications. Which is why I would rather see those who spend time developing profiles here, work together with upstream developers to bring both things together and create default profiles as part of upstream that are installed together with the applications by default. In the end this may not be adopted by the majority, but it is something that can be offered and perhaps we may see this become a thing for high risk applications eventually. A main challenge would be how to address abstractions when upstream is to add a single profile. Splitting apparmor.d into a package for abstractions may be one option, but that woudl still be unstable on roling release distros. The other option is to add everything to a single profile I suppose. Another idea would adopt the previously menationed manifest that defines agnostic access rules and may be interpreted by both the application and an apparmor profile generator. Think of apache reading such a manifest to change its own configuration for the DocumentRoot path and apparmor doing the same. It seems unlikely to be adopted I have to admit though. Ideally applications that parse untrusted data would all adapt a privilege separation architecture with seccomp and landlock at its core that provide this security boundary similar to browsers, but as I can say from my experience that is way too much work to come even close to a realistic solution. If that was the case though, apparmor could be the additional layer to provide additional security like implementing MLS, but it may be needed much rather for that first layer instead. Which is at least where I see the possible future of apparmor, as a android like ruleset that is build to not be touched by the end user at all and if at all to be managed only by administrators through additional rules. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
When using MAC mechanisms like apparmor, the administrator of a system is responsible for implementing the application profile rules and adjust them as needed. Apparmor.d makes this work a lot easier but the work of profiling an application to set the minimal privileged required for normal operations is still required and often edge cases are overlooked. The creation of permission rules by third parties or system administrators requires time to get familiar with the target appliction, testing and adjusting the profile then the application behavior changes with new releases. Apparmor.d provides tools to make this process quite easy but the work is still required.
A major argument for in process sandboxing (using seccomp, landlock) is the establishment of rules by the developer of the application itself and I always found that to be a most relevant point. However, these native process isolation can require quite a lot of work, as discussed in detail by this PhD thesis and consequently the adoption of native sandboxing in the open source ecosystem is quite low
So the question is if we can have both:
What if the packages of linux applications included apparmor profiles for their applications instead, installing these profiles together with the application?
Apparmor.d already provides profiles for most applications as well as the tooling to test and analyse issues.
So it would make sense to approach upstream developers with the proposal to integrate the respective profiles into their repositories and their CI to test them automatically with every change and release. This may lead to better maintained apparmor profiles that are also much more widely deployed and it also provides distributions with an incentive to enable apparmor by default. Since the essential features required for effective isolation are now all in the mainline kernel (since 6.17), that seems like a reasonable approach to me.
When upstream developers decide to integrate apprmor profiles, apparmor.d could replace the profile with a reference to the upstream profile file and file future profile improvements directly to upstream. In theory, if this approach gains popularity, it could eventually lead to apparmor.d dissolving into a reference database to upstream profiles, "concluding" the project successfully in a sense.
Im not sure how realistic this is but at least some form of integration into upstream could be achieved.
One open question would be how multiple profiles can be addressed. This is already an issue with the upstream apparmor userspace package that installs some profiles that are also provided by apparmor.d. It may need a scheme that allows a priority among the profiles for the same applications, with the upstream profile takign precedence, but also allowing the user to add rules that arent overwritten by updates.
The overall motivation for this is to have apparmor profiles that provide effective isolation but without the need for users to constantly update the profiles when new versions are released or even when libraries change their behavior. As much as I like playing around with profiles, the current apparmor ecosystem seems far from a sustainable security mechanism that could be deployed in a production environment without having constant maintenance and extensive testing. The same is true for SELinux btw. which I have not seen outside of RHEL systems because they maintain the rulesets. If we can change this towards a reliable solution, apparmor may gain significantly more popularity. In the end, the most successful security mechanisms seem to all have in common that users do not notice them, which is why I think the best approach apparmor.d can take is to focus on this invisibility.
What are your thoughts on this? @roddhjav @jrjohansen
Beta Was this translation helpful? Give feedback.
All reactions