Apparmor suggestion to include more profiles

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Apparmor suggestion to include more profiles

Bugzilla from jc@phocean.net
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


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Christian Boltz-7
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
--
"Wirklich praxisnah wären Münzen zu EUR 0,99."
[Wolfgang Schwanke in de.etc.sprache.deutsch]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Bugzilla from jc@phocean.net

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


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Christian Boltz-7
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
--
>Programmieren in C++ hält die grauen Zellen am Leben.
Es schaerft alle fuenf Sinne: den Schwachsinn, den Bloedsinn,
den Wahnsinn, den Unsinn und den Stumpfsinn.
[Felix von Leitner und Holger Veit in doc]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Johannes Meixner
In reply to this post by Christian Boltz-7

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
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Carlos E. R.-2
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.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Marcus Meissner
In reply to this post by Johannes Meixner
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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Johannes Meixner
In reply to this post by Carlos E. R.-2

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
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Christian Boltz-7
In reply to this post by Johannes Meixner
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.

--
* cboltz votes for the boring version - can't
<sarnold> that's a bit informal for a mandatory security platform :)
<sbeattie> ah, but you see, contractions are informal, and we can't,
           err can not, err cannot, err can ?not have that.
[from #apparmor, while discussing bugzilla.novell.com/853661]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Carlos E. R.-2
In reply to this post by 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.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Malte Gell-3
In reply to this post by Bugzilla from jc@phocean.net
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



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Christian Boltz-7
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
--
> Can we agree to disagree, or do we need to vote in the
> next meeting? ;-)
Wait, you want to start a discussion on which voting system
(http://en.wikipedia.org/wiki/Voting_system) to use? :)
[> Christian Boltz and Steve Beattie in apparmor]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Lew Wolfgang
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


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Carlos E. R.-2
-----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))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAldOPM8ACgkQja8UbcUWM1w+nQD/bfOGdO6nd3DlbQinQVGaWbjS
FE+d7kIwIYs21w0KIM0A+gNPfPJS69xpAQIG4tENad3SNc8rFhZUL0i8CCxx7AcW
=V/9f
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Johannes Meixner
In reply to this post by Christian Boltz-7

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
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Malte Gell-3
In reply to this post by Christian Boltz-7
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

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Anton Aylward-2
In reply to this post by Lew Wolfgang
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.

--
"To ask the right question is already half the solution of a problem".
   -- Carl Jung.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Anton Aylward-2
In reply to this post by Malte Gell-3
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?



--
     /"\
     \ / ASCII Ribbon Campaign
      X  Against HTML Mail
     / \
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Christian Boltz-7
In reply to this post by Malte Gell-3
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 :-)

--
Bitte in Zukunft keine Stasi-Vergleiche mehr. Das verharmlost die
gegenwärtige Situation. [purchaser auf
http://www.heise.de/newsticker/foren//forum-290681/msg-26347022/read/]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Apparmor suggestion to include more profiles

Carlos E. R.-2
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.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment