On Tuesday 10 January 2006 12:39, Pete Connolly wrote:

On Tuesday 10 January 2006 17:36, Andreas Jaeger wrote:

...

FYI: Novell has put AppArmor today into the open. AppArmor is an application security tool designed to provide a highly secure yet easy to use security framework for your applications, for further details check:

http://www.opensuse.org/Apparmor

The next update of FACTORY will contain the AppArmore packages - as well as 10.1 Beta1 which will be released next week,

Andreas

Excellent news. This is easily the easiest and most powerful containment technology I've used. I thought it might happen, just waiting to see.

Cheers

Pete

Excellent news... do we know if it will it be enabled by default, like SELinux on many other distros? Thanks, -Joseph M. Gaffney aka CuCullin

On Jan 10, 2006, at 10:22 AM, Andreas Jaeger wrote:

"Joseph M. Gaffney" writes:

...

Excellent news... do we know if it will it be enabled by default, like SELinux on many other distros?

I plan to install the packages by default if you do a basic installation.

Enabling of the profiles is something I'd like to see in the end - the question is whether the profiles can be preconfigured in such a way that the users do not need to make additional changes to have a working and secured system. So, for beta1 I plan to not enable it by default and hope that people enable for testing and report back.

But let's ask the AppArmor developers on what they think and how to help them best,

Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Hi All, The current profile set is defined for the SUSE 10.0 era application set - we shall start the process to update the profiles after beta1. As soon as we have stable profiles that we have validated against the 10.1 application set we want to enable AppArmor in the default install. You can help with this effort by testing an existing profile - or creating a new profile. The following is an overview - there is detailed coverage of this process in the Novell AppArmor Administrators guide (online http:// www.opensuse.org/Documentation) * Testing an existing profile: 1. Enable AppArmor It is a service that can be started like any other: "rcsubdomain start" 2. Restarting your application (e.g. apache, postfix) 3. Run your application 4. Update the profiles by running the update tools: - "logprof" is a command line tool that should be run as root - "YaST -> Novell AppArmor -> Update Profile Wizard" - is the YaST GUI equivalent Both of these tools will result in prompting you about the rejections and you can automatically update the profiles. This is only necessary if you see REJECT messages in /var/log/messages 5. Send your profile changes to this list or apparmor- general@forge.novell.com - (the profiles are stored in /etc/ subdomain.d/ - filename matches the program path that the profile is for) * Creating a new profile for an application (any application can be profiled but we generally view programs that accept network connections as the highest threat - and so in greatest need of protection) 1. Enable AppArmor It is a service that can be started like any other: "rcsubdomain start" 2. Run the console command "genprof program-binary-name" as root (YaST "Novell AppArmor -> Add Profile Wizard" is the YaST GUI equivalent). This starts the process and will prompt you to restart and run your application 3. Restart your application (e.g. apache, postfix) 4. Run your application 5. Stop the application 6. Return to the console window (from 2.) and press 'S' (or "Scan for events" in YaST) . This will scan the event log and guide you through creating your profile. 7. Send your profile to this list or apparmor- general@forge.novell.com - (the profiles are stored in /etc/ subdomain.d/ - filename matches the program path that the profile is for) The current profile set is below (can also be found by looking at the contents of /etc/subdomain.d). --- /usr/sbin/sshd /usr/sbin/httpd2-prefork /usr/sbin/squid /usr/sbin/sendmail /usr/sbin/postqueue /usr/sbin/postmap /usr/sbin/postdrop /usr/sbin/postalias /usr/sbin/ntpd /usr/sbin/nscd /usr/sbin/identd /usr/sbin/in.identd /usr/lib/postfix/trivial-rewrite /usr/lib/postfix/tlsmgr /usr/lib/postfix/smtpd /usr/lib/postfix/smtp /usr/lib/postfix/showq /usr/lib/postfix/scache /usr/lib/postfix/qmgr /usr/lib/postfix/proxymap /usr/lib/postfix/pickup /usr/lib/postfix/nqmgr /usr/lib/postfix/master /usr/lib/postfix/local /usr/lib/postfix/flush /usr/lib/postfix/cleanup /usr/lib/postfix/bounce /usr/lib/man-db/man /usr/lib/RealPlayer10/realplay /usr/bin/procmail /usr/bin/opera /usr/bin/man /usr/bin/ldd /usr/bin/apropos /usr/X11R6/bin/ethereal /usr/X11R6/bin/acroread /sbin/syslogd /sbin/klogd /opt/gnome/lib/evolution-data-server-1.2/evolution-data-server-1.4 /opt/gnome/lib/GConf/2/gconfd-2 /opt/gnome/bin/gaim /opt/gnome/bin/evolution-2.4 /opt/MozillaFirefox/lib/mozilla-xremote-client /opt/MozillaFirefox/lib/firefox-bin /opt/MozillaFirefox/bin/firefox.sh /bin/traceroute /usr/sbin/traceroute /bin/ping /bin/netstat --- thanks, -dominic

Christoph Thiel wrote:

On Tue, 10 Jan 2006, Dominic Reynolds wrote:

[...]

...

5. Send your profile changes to this list or apparmor-general@forge.novell.com - (the profiles are stored in /etc/subdomain.d/ - filename matches the program path that the profile is for)

I'd rather suggest the usage of Bugzilla (http://bugzilla.novell.com/) for submitting new profiles...

Regards Christoph

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

This is a good idea. So for people wanting to post a correction, or register problems with a profile you can add a BZ defect against the AppArmor component. Please list the application profile name in the summary for others to search on. Users can add updated profiles or a copy of /var/log/messages (which can be then used to update the profile set) as attachments to that BZ entry. We think that one BZ entry per use case works well for tracking issues. So for example: "Enabled local user access for /usr/sbin/vsftpd" would be a single BZ entry that users could update and query. thanks, dominic

Pete Connolly writes:

On Tuesday 10 January 2006 21:51, Christoph Thiel wrote:

...

On Tue, 10 Jan 2006, Dominic Reynolds wrote:

[...]

...

5. Send your profile changes to this list or apparmor-general@forge.novell.com - (the profiles are stored in /etc/subdomain.d/ - filename matches the program path that the profile is for)

I'd rather suggest the usage of Bugzilla (http://bugzilla.novell.com/) for submitting new profiles...

Regards Christoph

Can we use this for gathering a 'hitlist' of applications to be profiled, apart from the defaults that Dominic outlined earlier? I'm willing to put in the hours to profile the more common apps, seeing as this technology is now open-source.

I would suggest to create one or more wiki page on the opensuse wiki listing: * profiles done and integrated * profile wished * profiles worked on And then add references to bugzilla if a profile is submitted. Or whatever you think appropriate ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Tuesday 10 January 2006 18:22, Andreas Jaeger wrote:

"Joseph M. Gaffney" writes:

...

Excellent news... do we know if it will it be enabled by default, like SELinux on many other distros?

I plan to install the packages by default if you do a basic installation.

Good idea.

Enabling of the profiles is something I'd like to see in the end - the question is whether the profiles can be preconfigured in such a way that the users do not need to make additional changes to have a working and secured system. So, for beta1 I plan to not enable it by default and hope that people enable for testing and report back.

It might take a while to get to the 'enabled by default' stage. I was bitten in the early stages of using AppArmor by the simple fact of not remembering it was enabled to start at boot. You can get some strange results depending on the application, e.g. a PHP script that would try to start but immediately stop with an error stating that it couldn't read itself! You need to remember to watch the /var/log/messages file for subdomain errors.

But let's ask the AppArmor developers on what they think and how to help them best,

I'm very willing to contribute the few profiles that I've created - NetMail 3.5x, eDirectory 8.7x and one or two other more minor applications.

Andreas

Cheers Pete