Hello,
It is a nice thing that openSUSE includes apparmor by default. I started to play with it on Leap 42.1.
However, I feel it is a little short in term of profiles for the desktop (all profiles are server oriented).
In comparison, I retrieved the profiles in Ubuntu :
bzr co lp:apparmor-profiles
They have some profiles for chromium, firefox, empathy, totem, thunderbird and evolution among others. Some big candidates are still missing though, like Wireshark.
I feel such profiles are important, because these applications are rather exposed regarding modern threats.
Do you think it would be legally possible to include them more or less as is in Leap 42.2 and all future releases? Or at least, is there any plan to develop more profiles for the desktop?
Thank you in advance for your reply,
Best regards, Jean-Christophe
Hallo,
Am 29. Mai 2016, 15:37:07 CEST schrieb Jean-Christophe Baptiste:
It is a nice thing that openSUSE includes apparmor by default. I started to play with it on Leap 42.1.
However, I feel it is a little short in term of profiles for the desktop (all profiles are server oriented).
In comparison, I retrieved the profiles in Ubuntu :
bzr co lp:apparmor-profiles
They have some profiles for chromium, firefox, empathy, totem, thunderbird and evolution among others. Some big candidates are still missing though, like Wireshark.
I feel such profiles are important, because these applications are rather exposed regarding modern threats.
Do you think it would be legally possible to include them more or less
I don't see a problem with it - the repo contains a LICENSE file which declares its content as GPL v2.
as is in Leap 42.2 and all future releases? Or at least, is there any plan to develop more profiles for the desktop?
The problem with those profiles is that they include some restrictions the average user won't like ;-)
This is a general problem with profiles for desktop applications. As soon as an application comes with File - Open or File - Save as menu items, the profile can a) allow opening and saving files from a specified set of directories (for example, the Ubuntu firefox profile AFAIK allows saving files only to ~/download/). Unfortunately this will terribly annoy users. b) allow opening and saving files everywhere, which makes the profile pretty useless
The problem with annoying users is they will tend to just disable AppArmor, and, worse, will recommend this to other users whenever they hit an AppArmor restriction. That's something I'd really like to avoid.
There's also an option c) - implement an "external" file dialog that runs outside of the AppArmor restrictions. Unfortunately this only exists on the wishlist AFAIK, but it would solve most of the problems.
Another problem can be how desktop applications are implemented. For example, I'm playing with a profile for Konversation. In theory that sounds easy ("allow network communication, and allow to store the IRC logs").
Things become funny when you click a link posted on IRC, because Konversation first asks (via the KDE libraries etc.) which application handles this filetype, and then starts this application. So the profile needs to allow starting lots of applications (browser, text editor, image viewer etc. ) from Konversation.
This would need to get changed in Konversation itsself - instead of finding out itsself which application handles the given filetype and starting it, it should let an external program (let's call it konversation-link-clicked-helper, or maybe it could just use xdg-open) which could then be confined with a more permissive profile to allow starting other applications.
After probably disappointing you, I hope you are still interested in the profiles from lp:apparmor-profiles ;-)
You are more than welcome to test them and give feedback [1]. If some of them do not cause annoyances, I'm more than happy to package them in openSUSE.
BTW: An annoying detail is that lp:apparmor-profiles contains several dummies that only say "the profile for this application is packaged in $packagename", which makes it more difficult to get the actual profile. There are plans to get this fixed. I discussed it with some Debian people at DebConf15, and if we are lucky, they'll find some time to implement it at this year's DebConf next month.
I'm also thinking about creating an apparmor-profiles-paranoid [2] package. This package could contain "probably annoying" profiles and would only get installed when explicitely requested.
Regards,
Christian Boltz
[1] either here or on the upstream AppArmor mailinglist
[2] the name is inspired by /etc/permissions.secure which also includes some annoying restrictions
Thank you for your reply!
The problem with annoying users is they will tend to just disable AppArmor, and, worse, will recommend this to other users whenever they hit an AppArmor restriction. That's something I'd really like to avoid.
Yes, it makes perfect sense. We all want to avoid a SELinux situation :-) I personnally did use it for a while, but most people I know are disabling it.
After probably disappointing you, I hope you are still interested in the profiles from lp:apparmor-profiles ;-)
No problem, I am happy to have your point of view which is very instructive! :-) I will keep playing with them but with a different approach.
I am convinced that, while it is technically possible, we can never, in real life, implement this "white list" approach for any complex application. By white list, I mean trying to have a complete view of all features and actions that a given app is going to do on the system, and, based on that, trying to make a profile with allow/deny filters. We are doomed to spend enormous amount of times, forget some stuff or being too restrictive.
This approach aims to prevent an exploit to escalate its privileges. Under this constraints, an attacker cannot go beyond the normal behavior of the compromised application.
But I want to investigate another approach, because I think it does not make sense on the desktop. It does make sense on a server, because we want to avoid a privilege escalation on the OS, which could impact other services and help the attacker to maintain his access for a long time.
However, it is a different story on the desktop.
For instance, let's say my browser was compromised. As a user, do I really care if then the OS gets also compromised? Would it be even a priority for the attacker? Maybe, but in most cases, both will more care about the data, for instance what's in /home.
So why not having a simpler approach of blacklisting confidential folders? I am thinking about that .ssh or EncFS folder that contains secrets I really care about. Such a setting would be easy to configure and, I guess, very understood by the average user.
You can have such a setting in a file included in all profile, and you can make dummy packages for almost every application that just include this base file. I want to try such settings, which, along with notifications, would make a nice HIDS.
What do you think about it?
Best regards, Jean-Christophe
Hello,
Am 29. Mai 2016, 20:05:42 CEST schrieb Jean-Christophe Baptiste:
Thank you for your reply!
The problem with annoying users is they will tend to just disable AppArmor, and, worse, will recommend this to other users whenever they hit an AppArmor restriction. That's something I'd really like to avoid.
Yes, it makes perfect sense. We all want to avoid a SELinux situation :-) I personnally did use it for a while, but most people I know are disabling it.
I intentionally avoided to mention SELinux, but the situation you describe is also what I heard ;-)
After probably disappointing you, I hope you are still interested in the profiles from lp:apparmor-profiles ;-)
No problem, I am happy to have your point of view which is very instructive! :-) I will keep playing with them but with a different approach.
I am convinced that, while it is technically possible, we can never, in real life, implement this "white list" approach for any complex application. By white list, I mean trying to have a complete view of all features and actions that a given app is going to do on the system, and, based on that, trying to make a profile with allow/deny filters. We are doomed to spend enormous amount of times, forget some stuff or being too restrictive.
It's not impossible, "just" hard ;-) - I've even seen a working profile for LibreOffice which restricted it to the file types it can handle.
Of course, daemons are much easier to confine than anything with a File - Open menu item (or the CLI equivalent of it).
This approach aims to prevent an exploit to escalate its privileges. Under this constraints, an attacker cannot go beyond the normal behavior of the compromised application.
But I want to investigate another approach, because I think it does not make sense on the desktop. It does make sense on a server, because we want to avoid a privilege escalation on the OS, which could impact other services and help the attacker to maintain his access for a long time.
However, it is a different story on the desktop.
For instance, let's say my browser was compromised. As a user, do I really care if then the OS gets also compromised? Would it be even a priority for the attacker? Maybe, but in most cases, both will more care about the data, for instance what's in /home.
I'd say you should care for both. Of course an user will first care about his/her data - but with a compromised system, I'd argue that everything (including the data) can no longer be trusted.
That said - the system is usually protected by the file permissions already (assuming/hoping nobody starts firefox as root), so the focus can indeed be on protecting user data.
This brings us back to the File - Open and File - Save as problem ;-)
So why not having a simpler approach of blacklisting confidential folders? I am thinking about that .ssh or EncFS folder that contains secrets I really care about. Such a setting would be easy to configure and, I guess, very understood by the average user.
You might want to look at /etc/apparmor.d/abstractions/private-files and .../private-files-strict ;-)
You might also want to look at the sanitized_helper profile defined in /etc/apparmor.d/abstractions/ubuntu-helpers (typically included in other profiles as child profile, but using it as "real" profile should be easy). Please read the comment in the file before using it.
This is obviously not the best solution, but still better than nothing.
You can have such a setting in a file included in all profile, and you can make dummy packages for almost every application that just include this base file. I want to try such settings, which, along with notifications, would make a nice HIDS.
What do you think about it?
It's definitively worth a try ;-) and better than nothing.
Regards,
Christian Boltz
Hello,
perhaps off topic - more a question from someone who does not know any internals about AppArmor:
On May 29 18:10 Christian Boltz wrote (excerpt):
This is a general problem with profiles for desktop applications. As soon as an application comes with File - Open or File - Save as menu items, the profile can a) allow opening and saving files from a specified set of directories (for example, the Ubuntu firefox profile AFAIK allows saving files only to ~/download/). Unfortunately this will terribly annoy users. b) allow opening and saving files everywhere, which makes the profile pretty useless
I think when there is an explicit dialog whereto the application will save a file or wherefrom the application will read a file, there should be no need for additional restrictions because the user can see and confirm what file will be used and by standard Unix permissions a normal user cannot damage other user's data (basically "the system" is root's data).
In contrast when an application reads or writes files unnoticed by the user then I would like to have some restrictions set up so that the application cannot do "bad things".
In particular I would like that an application cannot unnoticed replace existing files (e.g. replace my private data by something else) and that an application cannot unnoticed read arbitrary files (e.g. read my private data and send it to someone in the Internet).
Is such a setup possibe with AppArmor?
I wonder how AppArmor (or any external tool) could know whether or not an application reads or writes files unnoticed versus via an explicit user confirmation dialog?
Kind Regards Johannes Meixner
On 2016-05-30 11:25, Johannes Meixner wrote:
I wonder how AppArmor (or any external tool) could know whether or not an application reads or writes files unnoticed versus via an explicit user confirmation dialog?
It is a very good point you mention.
Suppose LibreOffice is configured so that it can only open files in ~/Documents. Now suppose LibreOffice is trojaned, perhaps via a macro virus. It could open and trash every file in ~/Documents. Whereas if it is only allowed to write files explicitly mentioned in the open dialog, this would not happen.
But I don't see this is feasible. A Document can include other documents, for instance.
Hello,
On May 30 13:39 Carlos E. R. wrote (excerpt):
Suppose LibreOffice is configured so that it can only open files in ~/Documents. Now suppose LibreOffice is trojaned, perhaps via a macro virus. It could open and trash every file in ~/Documents.
Plain destruction is not a real problem. It is easily noticed and simply fixed (use your backup).
The problem is when it reads all your ~/Documents/* and sends them to someone else in the Internet so that later you can get tricked by social engineering that is very specifically made for you.
Kind Regards Johannes Meixner
On 2016-05-30 14:12, Johannes Meixner wrote:
Hello,
On May 30 13:39 Carlos E. R. wrote (excerpt):
Suppose LibreOffice is configured so that it can only open files in ~/Documents. Now suppose LibreOffice is trojaned, perhaps via a macro virus. It could open and trash every file in ~/Documents.
Plain destruction is not a real problem. It is easily noticed and simply fixed (use your backup).
It can be. It has not happened in Linux as far as I know, but in Windows people find suddenly their data files encrypted for a ransom. Backups, yes, but most people don't do even a monthly backup.
I know one guy on a business setup, exporting many files from a Linux server via samba to Windows clients that had many files corrupted in this way. He is doing periodic backups and checks to find out when the data files get corrupted and then stop the backup, lest the backup itself gets corrupted and rotated out.
The problem is when it reads all your ~/Documents/* and sends them to someone else in the Internet so that later you can get tricked by social engineering that is very specifically made for you.
Yes, that's also a real danger.
On Mon, May 30, 2016 at 11:25:45AM +0200, Johannes Meixner wrote:
Hello,
perhaps off topic - more a question from someone who does not know any internals about AppArmor:
On May 29 18:10 Christian Boltz wrote (excerpt):
This is a general problem with profiles for desktop applications. As soon as an application comes with File - Open or File - Save as menu items, the profile can a) allow opening and saving files from a specified set of directories (for example, the Ubuntu firefox profile AFAIK allows saving files only to ~/download/). Unfortunately this will terribly annoy users. b) allow opening and saving files everywhere, which makes the profile pretty useless
I think when there is an explicit dialog whereto the application will save a file or wherefrom the application will read a file, there should be no need for additional restrictions because the user can see and confirm what file will be used and by standard Unix permissions a normal user cannot damage other user's data (basically "the system" is root's data).
In contrast when an application reads or writes files unnoticed by the user then I would like to have some restrictions set up so that the application cannot do "bad things".
In particular I would like that an application cannot unnoticed replace existing files (e.g. replace my private data by something else) and that an application cannot unnoticed read arbitrary files (e.g. read my private data and send it to someone in the Internet).
Is such a setup possibe with AppArmor?
No.
I wonder how AppArmor (or any external tool) could know whether or not an application reads or writes files unnoticed versus via an explicit user confirmation dialog?
Apparmor is implemented by static file/directory path whitelisting rules in the kernel, it cannot distinguish between a user wanted action and malicious one (e.g. if there is a dialog or not).
Ciao, Marcus
Hello,
Am Montag, 30. Mai 2016, 11:25:45 CEST schrieb Johannes Meixner:
perhaps off topic - more a question from someone who does not know any internals about AppArmor:
I'll give an "AppArmor Crash Course" talk at the openSUSE conference next month to get you started with AppArmor ;-)
Maybe we could also talk about confining CUPS with an AppArmor profile (Ubuntu does this already, so we don't need to start from scratch)
On May 29 18:10 Christian Boltz wrote (excerpt):
This is a general problem with profiles for desktop applications. As soon as an application comes with File - Open or File - Save as menu items, the profile can a) allow opening and saving files from a specified set
of directories (for example, the Ubuntu firefox profile AFAIK allows saving files only to ~/download/). Unfortunately this will terribly annoy users.
b) allow opening and saving files everywhere, which makes
the profile pretty useless
I think when there is an explicit dialog whereto the application will save a file or wherefrom the application will read a file, there should be no need for additional restrictions because the user can see and confirm what file will be used and by standard Unix permissions
You are assuming bug-free and exploit-free software here.
While I would really like to have that, I'm afraid reality differs. Oh, and I never heard of malicious software that first displays a file dialog so that the user can decide which file to destroy or leak ;-)
The idea with the "external" file dialog is to allow access to the selected file on the fly [1], which also means access to other files (bypassing the file dialog) could be denied.
a normal user cannot damage other user's data (basically "the system" is root's data).
Right.
In contrast when an application reads or writes files unnoticed by the user then I would like to have some restrictions set up so that the application cannot do "bad things".
In particular I would like that an application cannot unnoticed replace existing files (e.g. replace my private data by something else) and that an application cannot unnoticed read arbitrary files (e.g. read my private data and send it to someone in the Internet).
Is such a setup possibe with AppArmor?
Not with the current code - this would need the "external" file dialogs.
Also, thinks like files embedded into a document (but stored in a separate file) make things much more interesting[tm]. However, let's first get the external file dialogs implemented before discussing these details ;-)
I wonder how AppArmor (or any external tool) could know whether or not an application reads or writes files unnoticed versus via an explicit user confirmation dialog?
As Marcus already wrote, this isn't possible - either a file is in the whitelist/profile or it isn't.
Regards,
Christian Boltz
[1] This can be done by temporarily adjusting the profile, by coping the file to a whitelisted directory etc. - but the technical details don't really matter in this discussion ;-) For bonus points, it could remember the recently used files of each application, so that "File - Open recently used files" also works.
Hello Christian,
On May 30 14:38 Christian Boltz wrote (excerpt):
I'll give an "AppArmor Crash Course" talk at the openSUSE conference next month to get you started with AppArmor ;-)
according to https://events.opensuse.org/conference/oSC16/schedule#2016-06-24 your "AppArmor Crash Course" is on Friday June 24 at 11:00 which is perfect for me to attend.
I look forward to seeing you there!
Kind Regards Johannes Meixner
Am 29.05.2016 um 15:37 schrieb Jean-Christophe Baptiste:
Hello,
It is a nice thing that openSUSE includes apparmor by default. I started to play with it on Leap 42.1.
However, I feel it is a little short in term of profiles for the desktop (all profiles are server oriented). (.....)
You´re right, SUSE never came with many really useful AA profiles. On the other hand, in my mind you always need to change AA profiles to meet your demands.
I took profiles for Firefox and Thunderbird from the web and adapted them for my needs. For other apps I created profiles from scratch.
I think no profiles may fit to your needs, you virtually always need to change them.
I suggest to create a new folder /etc/apparmor.d/templates and openSUSE puts all new profiles there and the user can enable them on demand.
Another good idea would be, if you have created some profiles, post them here, so other users can make use of them.
There should be a SUSE Wiki where we can post our custom made profiles.
Regards
Hello,
Am Dienstag, 31. Mai 2016, 02:51:11 CEST schrieb Malte Gell:
Am 29.05.2016 um 15:37 schrieb Jean-Christophe Baptiste:
It is a nice thing that openSUSE includes apparmor by default. I started to play with it on Leap 42.1.
However, I feel it is a little short in term of profiles for the desktop (all profiles are server oriented).> (.....)
You´re right, SUSE never came with many really useful AA profiles. On the other hand, in my mind you always need to change AA profiles to meet your demands.
Did you also need any changes in the profiles that are enabled by default? If so, please tell me - in many (not all) cases I consider this to be a bug in the profile ;-)
I took profiles for Firefox and Thunderbird from the web and adapted them for my needs. For other apps I created profiles from scratch.
I think no profiles may fit to your needs, you virtually always need to change them.
Well, at least if you want them as strict as possible.
I suggest to create a new folder /etc/apparmor.d/templates and openSUSE puts all new profiles there and the user can enable them on demand.
There is /usr/share/apparmor/extra-profiles/ with several profiles, but because nearly nobody uses them, they are mostly bitrotting :-( so please don't expect too much.
The profiles from there should in theory be proposed when you start a new profile with aa-genprof - but I just noticed this is broken :-(
I sent a fix for this upstream, so this will be fixed in the next AppArmor releases (2.9.4, 2.10.2 and 2.11, whenever they'll get released, will contain the fix). If you want to fix this yourself, feel free to grab the patch from https://lists.ubuntu.com/archives/apparmor/2016-June/009748.html ;-)
Another good idea would be, if you have created some profiles, post them here, so other users can make use of them.
There should be a SUSE Wiki where we can post our custom made profiles.
I agree that it would be good to have a place where profiles can be shared, but I'm not sure if the wiki is a good place. The problem I see is that the wiki makes it too easy to do malicious modifications to a profile.
There are plans to setup a cross-distribution repo for profiles (I discussed this with some Debian people at last year's DebConf, and if we are lucky, they'll work on it at DebConf this year. Please don't take this as a promise - I reminded them about the repo, but I don't have an answer yet.)
Until this repo is available, posting profiles to this mailinglist sounds good to me.
If it turns out that the list gets flooded by AppArmor profiles, we'll need to search for a different solution, but that would be a luxery problem ;-)
Regards,
Christian Boltz
On 05/31/2016 05:16 PM, Christian Boltz wrote:
Did you also need any changes in the profiles that are enabled by default? If so, please tell me - in many (not all) cases I consider this to be a bug in the profile;-)
Hi Christian,
It's great to see activity here! I'm new to Apparmor, I had to create some specific profiles for a customer last month, and I really like it.
But the included profiles for dovecot didn't work. I was pressed for time so I quickly hacked two of the profiles to get the server working. I'm sure I didn't do it right, and may have messed up the security posture, but at least the mail is flowing!
In this case all user's home directories are in /export/home1. Here are the updated profiles generated with the help of aa-logprof. This is on a 13.2 x86-64 system.
What's the right way to do dovecot with user's home directories in /export/home1? An environment variable somewhere?
usr.lib.dovecot.imap
# Last Modified: Tue May 3 13:55:56 2016 #include <tunables/dovecot> #include <tunables/global>
# ------------------------------------------------------------------ # # Copyright (C) 2009-2010 Canonical Ltd. # Copyright (C) 2011-2013 Christian Boltz # # This program is free software; you can redistribute it and/or # modify it under the terms of version 2 of the GNU General Public # License published by the Free Software Foundation. # # ------------------------------------------------------------------ # vim: ft=apparmor
/usr/lib/dovecot/imap { #include <abstractions/base> #include <abstractions/dovecot-common> #include <abstractions/nameservice> #include <local/usr.lib.dovecot.imap>
deny capability block_suspend,
capability setuid,
/export/home1/** rwlk, /usr/lib/dovecot/imap mr, /{,var/}run/dovecot/auth-master rw, /{,var/}run/dovecot/mounts r, @{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwlk, @{HOME} r,
}
And:
usr.lib.dovecot.dovecot-lda
# ------------------------------------------------------------------ # # Copyright (C) 2013-2016 Christian Boltz # # This program is free software; you can redistribute it and/or # modify it under the terms of version 2 of the GNU General Public # License published by the Free Software Foundation. # # ------------------------------------------------------------------ # vim: ft=apparmor
#include <tunables/global> #include <tunables/dovecot>
/usr/lib/dovecot/dovecot-lda { #include <abstractions/base> #include <abstractions/nameservice> #include <abstractions/dovecot-common>
capability setuid,
@{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwkl,
/etc/dovecot/** r, /proc/*/mounts r, owner /tmp/dovecot.lda.* rw, /{var/,}run/dovecot/mounts r, /usr/bin/doveconf mrix, /usr/lib/dovecot/dovecot-lda mrix, /usr/sbin/sendmail Cx,
# Site-specific additions and overrides. See local/README for details. #include <local/usr.lib.dovecot.dovecot-lda>
profile /usr/sbin/sendmail flags=(attach_disconnected) { # this profile is based on the usr.sbin.sendmail profile in extras # and should support both postfix' and sendmail's sendmail binary
#include <abstractions/base> #include <abstractions/consoles> #include <abstractions/nameservice> #include <abstractions/user-tmp> #include <abstractions/postfix-common>
capability sys_ptrace,
/etc/aliases rw, # newaliases is a symlink to sendmail, so it's /etc/aliases.db rw, # actually the same binary /etc/fstab r, /etc/hosts.allow r, /etc/hosts.deny r, /etc/mail/* r, /etc/mail/statistics rw, /etc/mtab r, /etc/postfix/aliases r, /etc/postfix/aliases.db rw, # newaliases again /etc/sendmail.cf r, /etc/sendmail.cw r, /etc/shells r, /proc/loadavg r, /proc/net/if_inet6 r, /root/.forward r, /root/dead.letter w, /usr/bin/procmail Px, /usr/lib/postfix/master Px, /usr/lib/postfix/showq Px, /usr/lib/postfix/smtpd Px, /usr/sbin/postalias Px, /usr/sbin/postdrop Px, /usr/sbin/postfix Px, /usr/sbin/postqueue Px, /usr/sbin/sendmail mrix, /usr/sbin/sendmail.postfix mrix, /usr/sbin/sendmail.sendmail mrix, /{var/,}run/sendmail.pid rwl, /{var/,}run/sm-client.pid rwl, /{var/,}run/utmp rw, /var/spool/clientmqueue/* rwl, /export/home1/mail/* rwl, /var/spool/mqueue/* rwl, /var/spool/postfix/maildrop/* rwl, /var/spool/postfix/public/pickup w, /var/spool/postfix/public/qmgr w, /var/spool/postfix/public/showq w, } }
Regards, Lew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-06-01 02:53, Lew Wolfgang wrote:
In this case all user's home directories are in /export/home1. Here are the updated profiles generated with the help of aa-logprof. This is on a 13.2 x86-64 system.
What's the right way to do dovecot with user's home directories in /export/home1? An environment variable somewhere?
A few alternatives.
There is /etc/apparmor.d/local/usr.lib.dovecot.imap, but also "/etc/apparmor.d/tunables/dovecot", and possibly "/etc/apparmor.d/tunables/home"
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith))
On 05/31/2016 08:53 PM, Lew Wolfgang wrote:
But the included profiles for dovecot didn't work. I was pressed for time so I quickly hacked two of the profiles to get the server working. I'm sure I didn't do it right, and may have messed up the security posture, but at least the mail is flowing!
When I was first faced with this I used a utility that scanned the logs and built a proposed settings file based on the global violation errors. It worked great, and was easy to add destination restrictions.
That being said, I'm now using Christian's package, more because it represents the "openSuse" norm than anything else.
Its quite ineligible and easy to understand and modify/customise. Christian points out the areas for this and what might be done in the inline comments.
Kudos to Christian for good work here.
Am 01.06.2016 um 02:16 schrieb Christian Boltz:
(...) You´re right, SUSE never came with many really useful AA profiles. On the other hand, in my mind you always need to change AA profiles to meet your demands.
Did you also need any changes in the profiles that are enabled by default? If so, please tell me - in many (not all) cases I consider this to be a bug in the profile ;-)
No, actually I never looked closer at the default profiles.... I´ve been more keen on user space programms like Firefox, VLC etc. I guess on desktop systems this may be the first doors an attacker would break into.
Where can you make suggestions for changes to default profiles/abstractions? Here or bugzilla?
I agree that it would be good to have a place where profiles can be shared, but I'm not sure if the wiki is a good place. The problem I see is that the wiki makes it too easy to do malicious modifications to a profile.
Can a certain wiki site not be restricted to allow only certain people to post stuff? Doesn´t openSUSE have a website that is run "normally" without wiki? So people could show and discuss their AA profiles here on the list and an admin looks over them and puts them on a static non-wiki web site?
There are plans to setup a cross-distribution repo for profiles (I discussed this with some Debian people at last year's DebConf (...)
In the long run that would be best, so all Linux users can benefit, no matter what distribution.
Regards
On 06/02/2016 01:22 AM, Malte Gell wrote:
Can a certain wiki site not be restricted to allow only certain people to post stuff?
It depends what you mean by 'certain". If you mean an open one such as Wikipedia, then probably not, since it's based on 'mass contribution'.
All the Wiki's I've installed have been geared to contributions only by register/approved users, with granularity of access levels, For example any registered user might comment in the comment field, but even so that may need approval by an editor/moderator, or if not approval then the possibility of review.
Mainline content is another level of access; that too can be subject to review/editing/approval.
While all this is S.O.P on things like WordPress blogs, there are many wiki engines that don't offer such features. I grew up using the Perl-based wikis derived from Leuf+Cunningham's original work, like TikiWiki. When I encountered the MediaWiki code I was amazed at how bloated and incapable it was by comparison.
I've used and set up and tested many wikis along the way, from very public ones to small-fast personal ones; they are great for documentation and because of what Wikipedia has done, the concept is familiar to most corporate workers, and they immediately pick up on the extensions that deal with, for example, comments and feedback that seem like blogs.
So, yes, in the sense that 'certain' means a site that has been designed with a capable wiki engine such as FosWiki, and the plugins for the levels of access control (role based perhaps) and correctly configured, the answer is yes. But isn't the issue of "correctly configured" always a proviso?
Hello,
Am Donnerstag, 2. Juni 2016, 07:22:25 CEST schrieb Malte Gell:
Am 01.06.2016 um 02:16 schrieb Christian Boltz:
(...) You´re right, SUSE never came with many really useful AA profiles. On the other hand, in my mind you always need to change AA profiles to meet your demands.
Did you also need any changes in the profiles that are enabled by default? If so, please tell me - in many (not all) cases I consider this to be a bug in the profile ;-)
No, actually I never looked closer at the default profiles.... I´ve been more keen on user space programms like Firefox, VLC etc. I guess on desktop systems this may be the first doors an attacker would break into.
Agreed, but as I already pointed out in another mail, it's close to impossible to ship default profiles for them that are safe and don't annoy users.
Where can you make suggestions for changes to default profiles/abstractions? Here or bugzilla?
I'm everywhere ;-) but bugzilla has the advantage that nothing gets lost.
I agree that it would be good to have a place where profiles can be shared, but I'm not sure if the wiki is a good place. The problem I see is that the wiki makes it too easy to do malicious modifications to a profile.
Can a certain wiki site not be restricted to allow only certain people to post stuff?
In theory yes, but managing access permissions in MediaWiki is a nightmare if you need more than the usual groups (basically admins and "normal" users). To make things worse, MediaWiki has a browsable version history, but not a "blame" feature to find out who last edited a line.
Doesn´t openSUSE have a website that is run "normally" without wiki? So people could show and discuss their AA profiles here on the list and an admin looks over them and puts them on a static non-wiki web site?
Review/moderation is an important point.
Your text sounds like you are describing a git repo ;-) which would be a much better solution than a static web page.
There are plans to setup a cross-distribution repo for profiles (I discussed this with some Debian people at last year's DebConf (...)
In the long run that would be best, so all Linux users can benefit, no matter what distribution.
I fully agree. The profiles are typically useable everywhere if you honor some small details (for example /lib/ vs. /lib64/ -> use /lib*/).
BTW: Even if it isn't one of the stated goals of AppArmor, it more than once was helpful to get cross-distribution collaboration improved. And I'm not only talking about sharing AppArmor profiles here ;-) [1]
Regards,
Christian Boltz
[1] I did my "AppArmor Crash Course" talk at DebConf last year. I was the only speaker with an openSUSE t-shirt ;-) and had a funny "Any relations between Debian and openSUSE" slide. Next month we'll have two speakers from DebConf15 at the openSUSE conference. I'm sure the things they work on are also relevant, useful and interesting for openSUSE :-)
On 2016-06-02 21:46, Christian Boltz wrote:
Can a certain wiki site not be restricted to allow only certain people to post stuff?
In theory yes, but managing access permissions in MediaWiki is a nightmare if you need more than the usual groups (basically admins and "normal" users). To make things worse, MediaWiki has a browsable version history, but not a "blame" feature to find out who last edited a line.
Just what Anton said in the other post.
-
Anton Aylward -
Carlos E. R. -
Christian Boltz -
Jean-Christophe Baptiste -
Johannes Meixner -
Lew Wolfgang -
Malte Gell -
Marcus Meissner