gefira blog

Hm.. when I hear that ‘the research says the [Duqu] Trojan exploited a previously unknown vulnerability embedded in Word files, allowing Duqu to modify computers’ security protection‘, I just can’t help but imagine my opening a car, tossing a book on the back seat and then later on, being unable to use the brakes anymore because the publisher had used a wrong type of ink, one that makes the disc brakes vaporise immediately upon the book’s opening on page 51 when it lands on the seat.

That’s simply insane.

András Veres-Szentkirályi has started a series on securing web services with Python; the first part deals with UserNameTokens and mentions sec-wall, the security proxy, yay!

Here’s a minimal lighttpd SSL/TLS reverse proxy configuration that allows for securing the traffic to plain HTTP servers using client certificates.

For easier management, the config has been broken into two modules, the main part and a list of variables. A caveat one needs to be aware of is that even though we’re interested in lighttd’s proxying capabilities only, we still need to configure everything as though lighttpd was going to serve plain HTTP traffic using static files – hence the need for configuring server.port and server.document-root.

The config files as well as the crypto material (courtesy of the Spring Python project) being used below can be also fetched from bitbucket. Of course, being uploaded to a public site, the private key is useless outside of a development environment and should never be used for anything close to production.

Enjoy

# Include necessary modules.
server.modules = ("mod_proxy", "mod_setenv")

# Include config variables.
include "./config-variables.conf"

server.document-root = my-dummy-document-root
server.username = my-username
server.groupname = my-groupname

# IP address or hostname to listen on.
server.bind = my-host
server.port = my-plain-http-port

$SERVER["socket"] == my-host + ":" + my-ssl-client-validation-port {

    ssl.engine = "enable"
    ssl.use-sslv2 = "disable"
    ssl.verifyclient.exportcert = "enable"
    ssl.verifyclient.username = "enable"

    proxy.server = ("" => (("host"=>my-backend-host,
                                     "port"=>my-backend-plain-http-port)))

    # Server certificate.
    ssl.pemfile = my-ssl-server-certificate-key

    # Verify client's certificate.
    ssl.verifyclient.activate = "enable"
    ssl.verifyclient.enforce = "enable"
    ssl.verifyclient.depth = my-verifyclient-depth
    ssl.ca-file = my-ca-certificate
}

var.my-host = "localhost"
var.my-ssl-client-validation-port = "17443"
var.my-plain-http-port = "18080"
var.my-backend-host = "localhost"
var.my-backend-plain-http-port = "28080"
var.my-dummy-document-root="./"
var.my-username="dsuch"
var.my-groupname="dsuch"
var.my-ssl-server-certificate-key = "server-pair.pem"
var.my-ca-certificate = "./ca-chain.pem"
var.my-verifyclient-depth = "3"

I had to implement a couple of things related to the validation of client SSL/TLS certificates – as returned by the ssl.SSLSocket.getpeercert(True) method – and I thought I’d share the code with others, I guess there’s never too much of sample code in that area. Turned out that everything went smoothly with ssl and M2Crypto and it’s all below. Note that the code downloads the certificate off the Internet but it will work properly with a client certificate as well – well, maybe except for the fact that getpeercert(True) returns a DER while get_server_certificate gives you a PEM – but otherwise it will work just fine. Cheers!

# -*- coding: utf-8 -*-
 
from __future__ import absolute_import, division, print_function, unicode_literals
 
# stdlib
import ssl
 
# M2Crypto
from M2Crypto import X509
 
# Grab a certificate from the nearest server ..
cert_pem = ssl.get_server_certificate(('duckduckgo.com', 443))
 
# .. let's start with converting PEM to DER ..
cert_der =  ssl.PEM_cert_to_DER_cert(cert_pem)
 
# .. how does the DER look like (not too pretty)..
print('\nDER:')
print(cert_der)
 
# .. M2Crypto has a bunch of useful functions ..
x509 = X509.load_cert_string(cert_pem, X509.FORMAT_PEM)
 
# .. does the certificate belong to a CA ..
print('\nIs it a CA:')
print(x509.check_ca())
 
# .. the fingerprint ..
fp = x509.get_fingerprint('sha1')
fp = ':'.join(fp[pos:pos+2] for pos in xrange(0, len(fp), 2))
print('\nSHA1 fingerprint:')
print(fp)
 
# .. serial number ..
print('\nSerial number:')
print(x509.get_serial_number())
 
# .. who has it been issued by ..
print('\nIssuer:')
print(x509.get_issuer())
 
# .. how about the subject's commonName and organization only ..
subject = x509.get_subject()
print('\nSubject\'s commonName and organization:')
print(subject.CN)
print(subject.O)
 
# .. public key's exponent ..
#    inspired by http://mail.python.org/pipermail/python-crypto/2004-August/000683.html
e_data = x509.get_pubkey().get_rsa().e
 
# First 4 bytes are the length of what then follows
length, e_raw = e_data[:4], e_data[4:]
 
e = 0
for c in e_raw:
    e = (e*256) + ord(c)
 
print('\nPublic key\'s exponent:')
print(e)

Nice folks at www.linuxsecurity.com have just published a new article on using the sec-wall security proxy with cURL and PycURL, the Python interface to the libcurl library, so if you’re looking for information on how to test services secured using sec-wall, either with HTTP Basic/Digest Auth, custom HTTP headers, XPath-based authentication, WS-Security or SSL/TLS client certificates then you won’t be disappointed. Enjoy!

One of the things sec-wall, a featured-packed high performance security proxy, provides is the support for securing access to resources using arbitrary XPath expressions. What is currently missing in the documentation though is an explanation of how one should use XML namespaces. The thing can be done and there’s a bug report regarding it which I’m going to fix and close in a day or two but just thought that in the meantime I’d blog about it.

So how would one go about creating a sec-wall config.py file that should let in only clients that use credentials akin to what’s below?

<?xml version="1.0" encoding="utf-8"?>
<a>
    <b>
        <username xmlns="http://example.com/myns1">foo</username>
        <c xmlns="http://example.com/myns2" password="bar" />
    </b>
</a>

The answer is pretty simple – etree.XPath objects accept a namespaces argument which ought to be a mapping between prefixes used in expressions and actual namespaces, so the config file should read like below:

# -*- coding: utf-8 -*-
 
# stdlib
import uuid
 
# lxml
from lxml import etree
 
# Don't share it with anyone.
INSTANCE_SECRET = '7bcb90942d994440af05d02b691ae86d'
 
# May be shared with the outside world.
INSTANCE_UNIQUE = uuid.uuid4().hex
 
# ##############################################################################
 
def xpath():
 
    username = 'foo'
    password = 'bar'
 
    xpath1 = "/a/b/myns1:username/text() = '{0}'".format(username)
    xpath2 = "//myns2:c/@password='{0}'".format(password)
 
    ns_dict = {
        'myns1': 'http://example.com/myns1',
        'myns2': 'http://example.com/myns2',
    }
 
    return {
        'xpath': True,
        'xpath-1': etree.XPath(xpath1, namespaces=ns_dict),
        'xpath-2': etree.XPath(xpath2, namespaces=ns_dict),
        'host': 'http://example.com/',
    }
 
urls = [
    ('/xpath', xpath()),
]

Solid, eh?

One of the niceties of sec-wall, the security proxy, is that it’s written in Python which means not only that one doesn’t have to learn yet another obscure configuration format summoned from the deepest levels of R’lyeh but also that it’s very easy to extend the config.py file.

For instance, by default all of the secrets need to be given in clear text and that can probably be sub-optimal for some people, so why don’t we customize the config file and have it use GnuPG with symmetric decryption via the python-gnupg wrapper?

Let’s install python-gnupg first (piece of cake):

$ sudo pip install python-gnupg

Let’s prepare the secret.ini file, an INI-formatted configuration file which contains all the secrets:

$ cat secret.ini
[secret]
INSTANCE_SECRET=756817c1e2b8443c9d6f728da9b2b5fd
admin=MySecretPassword
$

The file will be now encrypted using GnuPG (let’s say the password is ‘123′) ..

$ gpg --symmetric secret.ini
$

.. the result of which is a new secret.ini.gpg file and secret.ini may now be removed:

$ rm secret.ini
$

OK, we need the accompanying config.py file now, just like the one below:

# -*- coding: utf-8 -*-
 
# stdlib
import cStringIO, getpass, sys, uuid
from ConfigParser import ConfigParser
 
# python-gnupg
import gnupg
 
# Where are we expecting the secrets to be.
gpg_file = open('./secret.ini.gpg', "rb")
 
passphrase = getpass.getpass('Enter passphrase (will not be echoed back): ')
 
gpg = gnupg.GPG()
ini_data = str(gpg.decrypt_file(gpg_file, passphrase=passphrase))
 
# Exit early on an incorrect passphrase.
if not ini_data:
    print("Incorrect passphrase.")
    sys.exit(1)
 
# The passphrase was OK, proceed on to parsing the INI data.
config = ConfigParser()
config.readfp(cStringIO.StringIO(ini_data))
 
# Use the GPG-encrypted data.
INSTANCE_SECRET = config.get('secret', 'INSTANCE_SECRET')
 
# May be shared with the outside world.
INSTANCE_UNIQUE = uuid.uuid4().hex
 
# ##############################################################################
 
def admin():
    return {
        'basic-auth': True,
        'basic-auth-username':'user',
        'basic-auth-password':config.get('secret', 'admin'), # Uses GPG now.
        'basic-auth-realm':'Secure area',
        'host': 'http://example.com'
    }
 
def default():
    return {
        'ssl': True,
        'ssl-cert': True,
        'ssl-cert-commonName':INSTANCE_SECRET,
        'host': 'http://' + INSTANCE_SECRET
    }
 
urls = [
    ('/admin/', admin()),
    ('/*', default()),
]

Try starting the proxy now. If everything’s OK, if the passphrase you’ve supplied has been the same as the one used for encrypting the original INI file, the sec-wall instance will start in background as usual:

$ sec-wall --start .
Enter passphrase (will not be echoed back):
$ echo $?
0
$

If on the other hand the password wasn’t ‘123′, the proxy won’t start:

$ sec-wall --start .
Enter passphrase (will not be echoed back):
Incorrect passphrase.
$ echo $?
1
$

And that’s it! Couldn’t have been simpler, eh?

Na swoim Ubuntu używam Enterprise Architecta uruchamianego pod Wine. Pomimo tego, że lubię EA to jednak nie mam zbyt wielkiej nadziei na to, że Sparx Systems udostępni wersję opensource’ową w najbliższej przyszłości. Nie mam dostępu do źródeł EA, więc podwójnie nie mogę wierzyć temu jak ten program działa. Szczęśliwie, dzięki AppArmor, możliwe jest ograniczenie dostępu EA do wskazanych zasobów systemu, dzięki czemu wiem, że EA nie zagląda niepotrzebnie do ~/.ssh, /sbin czy innych miejsc, które – według mnie – nie są EA potrzebne do szczęścia.

Odkładając jednak na bok historie o koniach trojańskich wprowadzanych celowo przez producentów popularnego oprogramowania bez dostępu do źródeł, warto podejść do kwestii EA bardziej systematycznie i odpowiedzieć sobie na pytania, które stawia autor tej książki.

1. Co właściwie chcę ochronić?
   • Chcę ochronić prywatne dane swoje i swoich klientów, które znajdują się w systemie i podlegają przetwarzaniu przez EA. Dodatkowo chcę ochronić sam system – binaria, biblioteki, pliki konfiguracyjne itp.
2. Jakie są zagrożenia dla zasobów, które chcę ochronić?
   • Ze strony EA nie przewiduję większych kłopotów, nie przewiduje celowych niecnych działań. Bardziej obawiam się tego, że EA nie był projektowany do pracy z Linuksem i może niechcący żądać dostępu do prywatnych danych oraz do innych core’owych zasobów systemu. Dane te i zasoby mogłyby być np. cache’owane przez EA w swoich strukturach danych (w plikach konfiguracyjnych, bazach z projektami) przez co mogłyby niechcący wyjść poza mój system gdybym np. chciał komuś wysłać swój projekt .EAP. Inną kwestią jest to, że EA nie podlega w żaden sposób aktualizacji oprogramowania takiej jak wszystkie inne aplikacje Ubuntu – nie jest instalowany jako pakiet Ubuntu więc informacje o nowych wersjach EA otrzymuję z opóźnieniem. Może więc zdarzyć się sytuacja, że będzie istniał exploit dla EA, który będzie można uruchomić w moim systemie pomimo tego, że reszta systemu będzie na bieżąco aktualizowana. Exploit ten mógłby pozwolić na wydostanie się przez sieć z systemu np. danych dotyczących projektów dla klientów.
3. Na ile dobrze proponowane przeze mnie rozwiązanie chroni zasoby?
   • AppArmor jest dojrzałym rozwiązaniem stosowanym w o wiele bardziej zaawansowanych scenariuszach serwerowych i  otoczenie EA przez AppArmor oznacza użycie części możliwości AA. AppArmor ma wszystkie te możliwości, na których mi zależy – pozwala na wskazanie, do których zasobów może lub nie może mieć dostęp EA. Używam standardowej, sprawdzonej, funkcjonalności AA.
4. Jakie zagrożenia wprowadza proponowane rozwiązanie?
   • Wprowadzam do systemu nowy element – AppArmor chroniący EA – istnieje więc ryzyko, że zmiany które wprowadzam same będą zawierały błędy, że AppArmor będzie zawierał błędy, które negatywnie wpłyną na bezpieczeństwo i zabezpieczenia systemu. Nie przewiduję zagrożeń związanych z tym, że zwiększy się poziom skomplikowania interakcji EA oraz Wine z resztą systemu, ostatecznie po to chcę wprowadzić AppArmor, aby ograniczyć, a nie zwiększyć, kontakty EA i Wine z pozostałymi elementami systemu.
5. Jakie są koszty wprowadzonego rozwiązania?
   • Podstawowym kosztem jest czas poświęcony na utworzenie i utrzymanie odpowiedniej konfiguracji AppArmor. EA jest relatywnie małą aplikacją, więc kilka godzin wystarczy na utworzenie początkowej konfiguracji. Konfiguracja, na której mi zależy powinna być ścisła, chcę więc ograniczyć dostęp EA do konkretnych wersji bibliotek potrzebnych do działania – wiąże się więc z tym to, że przy zmianach wersji bibliotek (np. nowa wersja X-a, upgrade do nowszej wersji Ubuntu) potrzebne będą zmiany w konfiguracji AppArmor, przewiduję, że zajmie to także kilkadziesiąt minut miesięcznie. Kosztem jest także konieczność aktualizacji AppArmor do nowszych wersji – to jednak odbywa się automatycznie, Ubuntu pobiera nowe wersje oprogramowania do instalacji i pyta mnie o zgodę na instalację, nie zajmuje to więcej niż kilkanaście minut miesięcznie. Inną sprawą jest zapotrzebowanie AA na zasoby sprzętowe (procesor i miejsce na dysku), aczkolwiek te są bardzo małe i praktycznie niezauważalne przy wszystkich innych zainstalowanych aplikacjach.
6. Czy warto wprowadzić proponowane zabezpieczenia aby zminimalizować zagrożenia, biorąc pod uwagę koszty, które muszę ponieść oraz zagrożenia, które mogą zostać wprowadzone?
   • Pomimo tego, że nie przewiduję, aby zagrożenia ze strony EA były duże to koszty, które muszę ponieść, oraz zagrożenia ze strony AA są jeszcze mniejsze – tak, warto wprowadzić proponowane zabezpieczenia.

Skoro już podjąłem decyzję o użyciu AA, to musimy utworzyć profil Enterprise Architecta dla AppArmor, który będzie zawierał reguły mówiące AA na co pozwalamy Enterprise Architectowi. Profile AA rozszerzają, nie zastępują, standardowe uprawnienia UNIX-owe do zasobów systemu. Nadal więc występują rwx, setuid, sticky bit i przyjaciele, ale dodatkowo AA pozwala na ściślejsza kontrolę dostępu.

AppArmor operuje na ścieżkach do plików – trzeba wskazać, który program chcemy audytować podając właśnie jego ścieżkę. Ponieważ EA jest uruchamiany pod Wine, to AA nie widzi tak naprawdę EA tylko Wine. Na przyklad, u mnie na pulpicie ikonka EA uruchamia takie polecenie:

env WINEPREFIX="/home/dsuch/.wine" wine "C:\Program Files\Sparx Systems\EA\EA.exe"

więc dla AA programem, który jest uruchomiony, nie jest EA tylko Wine.

Nie chcę utworzyć profilu dla całego Wine’a, tylko dla EA, potrzebujemy w takim razie małego wrappera, skryptu shellowego, który opakuje nam EA wywoływane pod Wine i będzie miało swoją unikalną ścieżkę, którą będzie można audytować. Wrapper ten  u mnie jest umieszczony w /home/dsuch/bin/ea.sh i ma taką postać:

wine ~/.wine/drive_c/Program\ Files/Sparx\ Systems/EA/EA.exe

Taki skrypt można już potraktować poleceniem aa-genprof. Jak czytamy w manualu (man aa-genprof), program ten wspomaga tworzenie profili dla AA. To co zrobi aa-genprof, to utworzenie pustego profilu dla wrappera /home/dsuch/bin/ea.sh, zaznaczenie w logu auditd (domyślnie /var/log/audit/audit.log) albo w  /var/log/messages, że rozpoczyna się proces tworzenia profilu, aktywowanie profilu w trybie complain (nauki), a następnie aa-genprof będzie czekał aż pochodzę sobie po EA, cały czas rejestrując w logu do jakich zasobów dostępu żąda EA. Gdy już skończę pracować z EA, aa-genprof zada mi serię pytań – nad którymi warto zastanowić się – na temat tego, czy EA faktycznie powinien mieć dostęp do zasobów, z których korzystał. Profile są prostymi plikami tekstowymi o określonej składni, można więc dodatkowo tune’ować je manualnie, już po ich utworzeniu. Skończony profil można uruchomić w trybie enforce, co spowoduje, że AppArmor zacznie stosować reguły zdeklarowane w profilu.

Do samego aa-genprof, jak i do innych toolsów z rodziny AppArmor istnieje dobra dokumentacja, spójrzmy więc na ostateczny profil, który można pobrać tutaj.

Pierwszą rzeczą, którą trzeba zauważyć jest to, że profil zawiera subprofil dla Wine. Ma to sens, ponieważ wrapper uruchamia Wine w podprocesie, i chcemy w profilu określić jakie możliwości powinien lub nie powinien mieć Wine uruchamiany w kontekście tego konkretnego wrappera, dlatego właśnie profil wrappera zawiera subprofil Wine.

Profil wrappera zawiera 3 polecenia:

• #include <abstractions/base> – includuje wszystkie reguły z /etc/apparmor.d/abstractions/base do bieżącego profilu (do profilu wrappera /home/dsuch/bin/ea.sh). Dzięki includowaniu można wyodrębnić sobie zestaw reguł wspólnych dla różnych profilowanych aplikacji
• owner @{HOME}bin/ea.sh r, – pozwala w ogóle na odczyt skryptu. Bez tej reguły, pomimo tego, że w sensie uprawnień UNIX-owych jestem właścicielem /home/dsuch/bin/ea.sh i wrapper ma odpowiednie aytrybuty (-rwx——), to jednak nie mogę odczytywać tego skryptu.
  • Chwili uwagi wymaga też alias @{HOME}. Mamy do niego dostęp dzięki użyciu #include <tunables/global> na samej górze profilu, który z kolei includuje między innymi /etc/apparmor.d/tunables/home, w którym to pliku określone jest gdzie w naszym systemie znajdują się katalogi domowe użytkowników. W razie gdyby ktoś w swoim systemie stosował nie /home, ale np. /export/home, to może tam wskazać lokalizację katalogów domowych użytkowników. Dzięki temu w profilach możemy właśnie pisać @{HOME} a nie /home. Po prostu kolejna warstwa abstrakcji.
  • Z kolei prefiks owner mówi AA, żeby sprawdzić, że jestem właścicielem pliku @{HOME}bin/ea.sh – mogłoby zdarzyć się tak, że istniałby w systemie /home/gucio/bin/ea.sh, który miałby swój profil AA taki sam jak mój, i dzięki użyciu prefiksu owner AA nie pozwoliłby mi na uruchomienie wrappera Gucia, nawet gdyby wrapper Gucia miał ustawiony atrybut o+x, który standardowo pozwoliłby mi na jego uruchomienie.

• /usr/bin/wine cx, – pozwala wrapperowi na uruchomienie Wine’a (flaga x), oraz mówi, że istnieje subprofil dla Wine’a uruchamianego w ramach aktualnego profilu (flaga c, czyli child).

Na tym kończy się profil dla samego wrappera, dalej w profilu pojawia się subprofil, który określa do czego ma dostęp Wine uruchamiany z poziomu wrappera. Subprofil celowo jest wybitnie restrykcyjny i wskazuje na konkretne wersje bibliotek, z których może korzystać Wine uruchamiający EA. Subprofil można podzielić na kilka części:

• Podstawowe zależności – tutaj nie ma wielkiego wyboru, trzeba pozwolić na ich uruchomienie, są to core’owe komponenty, które przewijać się mogą w większości aplikacji (ld, libc, libpthread itp.)
• Fonty – cóż, fonty na pewno są potrzebne w aplikacji okienkowej. Nie miałem pojęcia, że w aż tyle miejsc trzeba zajrzeć, żeby aplikacja miała dostęp do fontów.
• Locale – no tak, locale na pewno są potrzebne.
• X + keymapa – także przyda się w aplikacji okienkowej
• Wine, core + biblioteki – tu też nie ma wyboru, Wine nie jest mały, trzeba pozwolić na uruchomienie kilku podprocesów i wczytanie bibliotek.
• Wine, zasoby z pseudodysku C: – kolejne zależności Wine, tym razem bliższe systemowi Windows.
• /proc/cpuinfo i /proc/meminfo – potrzebne Wine do szczęścia.
• Ustawienia EA – tutaj dopiero zaczynają się ustawienia specyficzne dla EA. Nie ma wyboru, trzeba pozwolić EA na zajrzenie i wczytanie swoich własnych danych i bibliotek.
• Różne – tutaj nie ma nic ciekawego, nie ma też co dziwić się, że jest potrzebny dostęp do /etc/passwd, w jakiś sposób aplikacja musi sprawdzić gdzie np. jest mój katalog domowy. Wywołuje więc polecenie systemowe, które zagląda do /etc/passwd, odczytuje lokalizację mojego $HOME i zwraca wynik do aplikacji. Hasha i salta hasła w /etc/passwd i tak przecież nie ma.
• Ustawienia specyficzne dla moich projektów – wszystkie projekty, które wymagają jakichkolwiek diagramów UML, znajdują się w podkatalogach katalogu /home/dsuch/projects/, EA musi więc mieć dostęp do odczytu do tych podkatalogów. Dodatkowo, same projekty .eap przechowywane są zawsze w katalogach o nazwie “doc”, EA powinien mieć więc możliwość zapisywania do swoich plików i zakładania locka na pliku .ldb (flaga k oznacza granta na zakładanie locka na danym pliku).
• Zasoby, do których uprawnienia EA odebrałem – tu jest ciekawiej. Zasoby te można podzielić na trzy kategorie:
  • kryptobiblioteki – być może byłyby potrzebne gdybym EA dopiero instalował, np. EA potrzebowałby ich do sprawdzenia kluczy licencyjnych. Właściwie to jest dość pozytywne, że EA chce korzystać z możliwości krypto, które oferuje dany system a nie z własnych “innowacji”. Inna sprawa to to, że nie mam dostępu do źródeł EA, więc nie wiem na ile solidnie jest cała kryptografia w EA wykonana.
  • dostęp do sieci – to nie powinno być potrzebne. Nie mam pojęcia dlaczego, ale EA chciał koniecznie otwierać sockety TCP. Używam EA w wersji Professional Edition, nie łączę się więc z żadnymi bazami danych i nie chcę, aby EA otwierał jakiekolwiek połączenia. Z pewnością jest to sprawa do zgłoszenia do supportu SparxSystems, zobaczymy co support na to powie.
  • lista urządzeń SCSI (/proc/scsi/scsi) – teoretycznie nic groźnego, ale jeśli wszystko działa poprawnie bez tego to nie ma potrzeby nadawać takich uprawnień. To też jest sprawa dla supportu.

Na tym kończy się mój profil AppArmor dla Enterprise Architecta. Jestem zadowolony z tego, że EA nie wygłupia się i nie sięga tam, gdzie nie trzeba. Sprawę z otwieraniem socketów oraz SCSI zgłoszę w supporcie SparxSystems a odpowiedź opiszę tutaj. Widać wyraźnie, że profil w większości składa się z reguł dla Wine, nie dla EA – gdybym używał więcej aplikacji pod Wine to mógłbym część commonową dla Wine umieścić w osobnym profilu, który includowałbym w profilu dla EA.

Nie kończy się jednak na tym AppArmor, to dopiero czubek góry lodowej – zachęcam do zapoznania się z dokumentacją AppArmor i rozpoznania bardziej zaawansowanych możliwości.

Support społeczności Ubuntu dla AppArmor znajduje się na Launchpadzie, support komercyjny dla Ubuntu i AppArmor świadczy Canonical, a w Polsce support komercyjny dla Ubuntu oraz AppArmor oferuje gefira / the knowledge company.