Il 4 novembre 2025 SUSE ha annunciato SLES 16.0, con SELinux che sostituisce AppArmor come framework di controllo degli accessi obbligatorio predefinito. Se il server esegue SLES 16, non dare per scontato che AppArmor sia installato o attivo: verificare il framework supportato da tale implementazione prima di utilizzare questi comandi. La procedura seguente segue la documentazione di SUSE relativa ad AppArmor per SLES 15 SP7, dove AppArmor è installato ed eseguito per impostazione predefinita.
Su SLES 15 SP7, il percorso pratico per un'applicazione personalizzata è quello di aa-genprofcreare un profilo iniziale, testare l'applicazione in modalità di segnalazione, esaminare ogni richiesta registrata e quindi verificare che il profilo venga applicato correttamente. L'esempio utilizza un eseguibile ipotetico in /usr/local/bin/report-worker; sostituirlo con il percorso eseguibile reale della propria applicazione.
I profili AppArmor sono policy di testo memorizzate in /etc/apparmor.d. Il apparmor-utilspacchetto fornisce gli strumenti di profilazione. Controlla l'host e identifica l'eseguibile effettivo, incluso se un'unità systemd avvia un wrapper o un processo figlio:
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
SUSE indica AppArmor come abilitato di default nelle installazioni di SLES 15. Se gli strumenti o il pattern AppArmor completo non sono presenti, installarlo con sudo zypper in -t pattern apparmor. Se AppArmor non è attivo, è necessario individuarne la causa prima di eseguire la profilazione, anziché presumere che un file di profilo da solo fornisca protezione. Un profilo è associato a un percorso eseguibile; la profilazione di un wrapper quando il carico di lavoro reale viene eseguito come un altro binario potrebbe lasciare il processo importante non protetto.
Avvia il generatore. Interrompi l'applicazione se è già in esecuzione, quindi avvia la generazione del profilo:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
Il nome del servizio è un esempio. Utilizzare il nome reale dell'unità oppure omettere il comando di arresto se il programma non è in esecuzione. aa-genprofCrea un profilo approssimativo quando non ne esiste uno, lo mette in modalità di reclamo (apprendimento), lo ricarica e contrassegna il registro. La modalità di reclamo registra le richieste fuori policy ma le consente; è uno stato di apprendimento temporaneo, non di applicazione.
Esegui simulazioni di comportamento reale dell'applicazione. Mantieni il generatore aperto. In un altro terminale, avvia il servizio ed esegui processi o funzionalità rappresentativi:
sudo systemctl start report-worker
sudo journalctl -f
Il profilo deve coprire l'avvio normale, i percorsi di input e output previsti, le attività pianificate, la gestione degli errori e qualsiasi programma di supporto avviato dall'applicazione. Un profilo può apprendere solo le richieste generate durante il test. Non utilizzare carichi di lavoro sensibili all'ambiente di produzione solo per generare eventi; è preferibile un ambiente di test sicuro e dati di test rappresentativi.
Esamina ogni richiesta di accesso. Torna indietro aa-genprofe premi Sper analizzare l'intervallo di registro contrassegnato. Per ogni richiesta, decidi se l'applicazione necessita effettivamente di quel file, di quella funzionalità o di quella transizione tra programmi figli. Consenti il percorso e l'autorizzazione più ristretti e utili. Accetta un'astrazione quando copre accuratamente un'attività comune; usa un pattern glob solo quando i file corrispondenti condividono gli stessi requisiti di fiducia e di accesso. Nega o ignora le richieste incidentali o non spiegate.
Presta particolare attenzione alle richieste di esecuzione. Una transizione non vincolata può consentire a un elemento figlio di eludere la policy dell'elemento padre; utilizzala solo quando vi è una giustificata necessità di progettazione. Ripeti il ciclo di esercizio e scansione dopo aver aggiunto regole legittime. Quando il profilo copre il comportamento testato, termina il generatore. SUSE fa notare che il completamento di un nuovo aa-genprofciclo di apprendimento normalmente mette il suo profilo in modalità di applicazione.
Esamina la policy generata. Per questo percorso di esempio, la convenzione di denominazione di SUSE converte le barre nel percorso dell'eseguibile in punti, producendo /etc/apparmor.d/usr.local.bin.report-worker. Esamina il risultato invece di considerare le regole generate come automaticamente sicure:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Verifica che il profilo nomini l'eseguibile previsto, utilizzi gli include necessari e conceda l'accesso solo alla configurazione, ai dati, ai log, ai socket e ai programmi di supporto di cui l'applicazione ha effettivamente bisogno. Evita regole generiche come l'accesso illimitato a una sottocartella /o a un'intera directory scrivibile solo per evitare un rifiuto. L'applicazione dipende comunque dalla normale proprietà e dai permessi di Unix; AppArmor aggiunge un ulteriore livello di restrizione.
Impostare esplicitamente la modalità desiderata. Dopo la revisione, applicare il profilo al programma personalizzato:
sudo aa-enforce /usr/local/bin/report-worker
Se hai modificato il profilo manualmente dopo l'uscita del generatore, ricarica il set di profili con sudo systemctl reload apparmor. I documenti SUSE vengono ricaricati come profili di scansione senza sbloccare i processi in esecuzione. Riavvia il servizio dell'applicazione in modo che la nuova policy venga applicata al suo processo.
Eseguire nuovamente le stesse attività rappresentative mentre il profilo è in modalità di applicazione. Verificare che il servizio si avvii, legga gli input previsti, scriva l'output atteso e sia in grado di eseguire le operazioni di supporto o di rete richieste. Quindi, esaminare sia lo stato del profilo che i messaggi recenti del kernel:
sudo aa-status
sudo journalctl -k -g apparmor --since today
L'eseguibile personalizzato dovrebbe apparire caricato e in modalità di applicazione. I rifiuti di AppArmor nel registro del kernel identificano le richieste bloccate dalla policy; utilizzali per diagnosticare un errore reale dell'applicazione, non come motivo per consentire ogni percorso registrato. Per un permesso mancante legittimo, esegui sudo aa-logprof, esamina il suggerimento, aggiorna la regola in modo specifico, ricarica se l'hai modificata manualmente e riesegui il percorso dell'applicazione interessato.
Per un servizio in esecuzione continua la cui profilazione deve estendersi ai riavvii o a periodi di osservazione più lunghi, SUSE documenta un flusso di lavoro di sistema separato che utilizza aa-autodepscansioni aa-complainripetute aa-logprof. Il metodo autonomo aa-genprofè più semplice quando l'esecuzione di apprendimento può rimanere aperta per l'intera durata del test. Nessuno dei due flussi di lavoro può dedurre il comportamento dell'applicazione che non è mai stato eseguito, quindi è necessario tenere sotto controllo il profilo in caso di modifiche al software o alla configurazione.
SLES 15 SP5 può essere migrato online a SP6, ma ogni nodo deve essere riavviato. Utilizzare un aggiornamento progressivo testato o un passaggio di consegne blue-green per mantenere i carichi di lavoro raggiungibili.
Creare, perfezionare e verificare un profilo AppArmor con privilegi minimi su SLES 15 SP7, con una nota chiara sull'impostazione predefinita di SELinux in SLES 16.
Utilizza il profilo STIG supportato da SUSE per analizzare SLES 15, testare le soluzioni, rivedere i risultati rimanenti e conservare le prove di valutazione.
Tracciare una connessione Cockpit non riuscita attraverso DNS, porta 9090, socket systemd, firewalld, TLS e impostazioni di accesso, seguendo le linee guida SUSE aggiornate.
Crea una connessione Ethernet ridondante su SLES 15 con YaST e Wicked, configura il bonding attivo-backup e verifica entrambe le porte e il failover.
Trasforma un sistema SLES 15 esistente in un profilo AutoYaST verificato, convalidalo e utilizzalo per implementare un server di test con un numero ridotto di passaggi manuali.
Installa gli strumenti KVM e libvirt di SLES 15, abilita il servizio host corretto e configura le macchine virtuali selezionate per l'avvio automatico dopo un riavvio.
Utilizza i processi systemd e il registro di avvio precedente per individuare un servizio, un punto di montaggio o una dipendenza di archiviazione che rallenta il sistema, quindi correggi il problema senza mascherarne la causa.
Utilizza firewall-cmd per ispezionare la zona attiva, consentire HTTP in modo sicuro, preservare l'accesso SSH e verificare che la regola sopravviva a un riavvio su SLES 15.
Individuare la causa di un errore PAM, ovvero il servizio, i criteri dell'account o il provider di identità, quindi ripristinare la corretta configurazione SLES preservando una sessione amministrativa funzionante.
