openSUSE

[emanuc]

Non è cosi? Mi sai indicare una fonte cosi mi informo?

AppArmor, Seccomp and device permissions
When a snap is installed, its metadata is examined and is used to derive AppArmor profiles, Seccomp filters and device cgroup rules, alongside traditional permissions. This combination provides strong application confinement and isolation

https://snapcraft.io/docs/security-poli ... ermissions

PS: Infatti, nelle distro senza AppArmor o prive delle patch che Canonical mantiene e che non sono upstream, gli snap hanno un confinamento indebolito, rendendoli meno sicuri. Con la conseguenza che un utente, installando snap su altre distro senza le patch di AppArmor o su una distro con SELinux, si ritrova applicazioni non completamente confinate e quindi insicure. -.-

[woddy68]

Su Fedora è preinstallato il tool "setroubleshoot" che notifica in caso di accessi negati e aiuta a diagnosticare il problema. Guarda se c'è anche su openSUSE.

Sempre a proposito di user-friendliness e di trasparenza! Il tool più temuto (e ignorato) di Fedora/RHEL.

Abbiamo capito la tua avversione a Fedora e SElinux, ma esiste un tool di AppArmor in Ubuntu-Debian ?

Se leggi un post sopra lo scopri.

Perché discutiamo di Ubuntu-Debian-Fedora in un thread di Opensuse? Ci stiamo sempre a misurare il pisellino con gli altri pinguini?

Perché siamo al bar ?

Beh ok ma non è necessario comunque cercare sempre confronti off-topic anche se siamo al bar, no? A un certo punto se OpenSuse prende una decisione la responsabilità è sua, non di Fedora o Ubuntu.

A me incuriosisce veramente capire il motivo/i di questa decisione.

Ma mi prendi per il c...?
Io scrivo che openSUSE passa a SELinux e tu già al primo post rispondi

Padroneggio poco sia Apparmor che SElinux, quindi magari la mia critica è capziosa. Ma penso che come scelta sia dettata semplicemente dal voler riciclare/riutilizzare il lavoro che RedHat ha fatto fin'ora (visto che SEL è default su RHEL e su Fedora). Poi magari mi sbaglio, ci sarà sicuramente un controllo più granulare sui permessi, la sicurezza aumenterà, come asserisce il blogpost... Però un cambiamento così sostanziale porterà inevitabilmente tanti problemi per l'end user. I file vanno "taggati" con i contesti giusti, vanno "ri-contestualizzati" quando spostati da altri volumi o da altre directory con contesti diversi. Complicazioni in più, mentre con Apparmor si va relativamente lisci in quanto il controllo dei permessi non prevede l'utilizzo di metadati sul filesystem. Perlomeno non hanno cancellato il supporto ad Apparmor, e uno può ancora scegliere.

Come succede in tanti casi di rhelliani/fedoriani che conosco, finirà per mettere SELINUX=permissive per evitare menate aggiuntive. E così tanti saluti alla "sicurezza aggiuntiva", anzi si avrà un peggioramento. 

...e vieni a dire a noi che andiamo

[frapox]

Su Fedora è preinstallato il tool "setroubleshoot" che notifica in caso di accessi negati e aiuta a diagnosticare il problema. Guarda se c'è anche su openSUSE.

Sempre a proposito di user-friendliness e di trasparenza! Il tool più temuto (e ignorato) di Fedora/RHEL.

Abbiamo capito la tua avversione a Fedora e SElinux, ma esiste un tool di AppArmor in Ubuntu-Debian ?

Se leggi un post sopra lo scopri.

Perché discutiamo di Ubuntu-Debian-Fedora in un thread di Opensuse? Ci stiamo sempre a misurare il pisellino con gli altri pinguini?

Perché siamo al bar ?

Beh ok ma non è necessario comunque cercare sempre confronti off-topic anche se siamo al bar, no? A un certo punto se OpenSuse prende una decisione la responsabilità è sua, non di Fedora o Ubuntu.

A me incuriosisce veramente capire il motivo/i di questa decisione.

Ma mi prendi per il c...?
Io scrivo che openSUSE passa a SELinux e tu già al primo post rispondi

Padroneggio poco sia Apparmor che SElinux, quindi magari la mia critica è capziosa. Ma penso che come scelta sia dettata semplicemente dal voler riciclare/riutilizzare il lavoro che RedHat ha fatto fin'ora (visto che SEL è default su RHEL e su Fedora). Poi magari mi sbaglio, ci sarà sicuramente un controllo più granulare sui permessi, la sicurezza aumenterà, come asserisce il blogpost... Però un cambiamento così sostanziale porterà inevitabilmente tanti problemi per l'end user. I file vanno "taggati" con i contesti giusti, vanno "ri-contestualizzati" quando spostati da altri volumi o da altre directory con contesti diversi. Complicazioni in più, mentre con Apparmor si va relativamente lisci in quanto il controllo dei permessi non prevede l'utilizzo di metadati sul filesystem. Perlomeno non hanno cancellato il supporto ad Apparmor, e uno può ancora scegliere.

Come succede in tanti casi di rhelliani/fedoriani che conosco, finirà per mettere SELINUX=permissive per evitare menate aggiuntive. E così tanti saluti alla "sicurezza aggiuntiva", anzi si avrà un peggioramento. 

...e vieni a dire a noi che andiamo

Belli questi quote ultra nidificati, ora li faccio anch'io.

Woddy,. il mio citare fedora e rhel era semplicemente per dare un'opinione sul possibile scenario che può aprirsi dopo questo switchover. Purtroppo è l'unico precedente di implementazione di SEL che io sappia.

Non ho tirato in ballo fedora, rhel o ubuntu per fare un confronto a chi ha il pisellino più lungo. Volevo capirci qualcosa in più e dire la mia, in base anche alla mia esperienza (poca, come ho riconosciuto da subito).

Ubuntu l'hai tirato fuori tu. Non avrei dovuto risponderti, errore mio (ma l'ho capito dopo), perché che Ubuntu abbia o meno un'interfaccia per AppArmor non è un tuo problema di utente OpenSuse.

Quindi, con un tono che credevo si capisse fosse leggero, il mio intento era quello di capirne di più su questa decisione, senza prendere per il culo te o altri. Però vedo che hai frainteso le mie intenzioni e ti sei messo sulla difensiva, quando ho solo chiesto se era necessario continuare a confrontarsi (e a misurarsi) con altre distro.

A ora io francamente non ho capito appieno il razionale di questa decisione. Per lo meno, non mi pare sia stato detto. E se invece è stato detto, aiutami a capirlo (senza spocchia, senza sicumera, e senza aggressività possibilmente). Perché tanto nessuno ha la verità in tasca. Altrimenti, pace, la discussione finisce qua. Andrò a informarmi per conto mio, eventualmente.

Ti invito a moderare i toni perché, si, siamo al bar, ma a tutto c'è un limite.

Ciao.

[frapox]

Non è cosi? Mi sai indicare una fonte cosi mi informo?

AppArmor, Seccomp and device permissions
When a snap is installed, its metadata is examined and is used to derive AppArmor profiles, Seccomp filters and device cgroup rules, alongside traditional permissions. This combination provides strong application confinement and isolation

https://snapcraft.io/docs/security-poli ... ermissions

PS: Infatti, nelle distro senza AppArmor o prive delle patch che Canonical mantiene e che non sono upstream, gli snap hanno un confinamento indebolito, rendendoli meno sicuri. Con la conseguenza che un utente, installando snap su altre distro senza le patch di AppArmor o su una distro con SELinux, si ritrova applicazioni non completamente confinate e quindi insicure. -.-

quindi chiaramente Apparmor viene coinvolto in una certa misura nella gestione dei permessi degli Snap su Ubuntu, quindi quella gui in parte si appoggia ad AppArmor, ed è quindi (semplificando, e in modo limitato) una Gui per AppArmor.

Poi certo, non c'è una Gui dedicata, specifica alla creazione e gestione delle policy AppArmor, questo lo riconosco.

[woddy68]

Non è cosi? Mi sai indicare una fonte cosi mi informo?

AppArmor, Seccomp and device permissions
When a snap is installed, its metadata is examined and is used to derive AppArmor profiles, Seccomp filters and device cgroup rules, alongside traditional permissions. This combination provides strong application confinement and isolation

https://snapcraft.io/docs/security-poli ... ermissions

PS: Infatti, nelle distro senza AppArmor o prive delle patch che Canonical mantiene e che non sono upstream, gli snap hanno un confinamento indebolito, rendendoli meno sicuri. Con la conseguenza che un utente, installando snap su altre distro senza le patch di AppArmor o su una distro con SELinux, si ritrova applicazioni non completamente confinate e quindi insicure. -.-

quindi chiaramente Apparmor viene coinvolto in una certa misura nella gestione dei permessi degli Snap su Ubuntu, quindi quella gui in parte si appoggia ad AppArmor, ed è quindi (semplificando, e in modo limitato) una Gui per AppArmor.

Poi certo, non c'è una Gui dedicata, specifica alla creazione e gestione delle policy AppArmor, questo lo riconosco.

Rispondendo anche al precedente, nessuno sta facendo confronti, è ovvio che se si parla di SElinux in openSUSE tu possa dire che la tua esperienza in Fedora sia stata pessima, nessuno lo vieta, ma come tu sai ogni distribuzione può applicare politiche diverse a SElinux. Io posso solo dire che ho fatto alcune piccole modifiche di sistema e non ho avuto problemi, ma non escludo che in altri casi c'è ne possano essere.
Gli snap e AppArmor sono strettamente collegati se vuoi che gli snap siano confinati come dovrebbero essere e per questo c'è una GUI per poter gestire i permessi, come c'è anche con i flatpak, mi aspetto che in futuro entrambi i pacchetti rendano la richiesta dei permessi in stile Android, sarebbe bello e intuitivo.
Tuttavia AppArmor non è lì solo per gli snap, c'è sempre stato, ma da quel che ricordo manca di una GUI, in openSUSE c'è e puoi creare profili senza ricorrere a file di testo o terminale, il problema è che i profili erano pochi e molto permissivi.
Non è che openSUSE ha abbandonato AppArmor in favore di SElinux, è cambiata solo l'impostazione predefinita, ma in fase di installazione con un click puoi abilitare AppArmor.
Tra l'altro AppArmor fu sviluppato proprio da SUSE (all'epoca Novell), proprio per avere un'alternativa a SElinux che all'epoca era ritenuto un'incubo da gestire su desktop, ma stiamo parlando di un'era fa in termini tecnologici e oggi le cose forse sono un po' cambiate, in tutti i sensi.
Spero che ora ci siamo chiariti.

[frapox]

@woddy68 SELinux e AppArmor non sono direttamente paragonabili. per questo secondo me non ha senso fare confronti tra distro che usano MAC diversi. SELinux ha ¨l'etichettatura" del filesystem che AppArmor non usa. Ogni etichetta (contesto) presenta QUATTRO campi (user:role:type:level). C'è tutto un set di comandi appositi per gestire queste proprietà, e le policy che poi si basano su queste. Questo era così prima ed è ancora così, semplicemente perché è il cuore dell'implementazione di SE Linux.

Per questo dico che possono insorgere problemi e complicazioni nel caso l'utente non conosca queste cose (e, fidati, che neanche tra i professionisti IT c'è chi le conosce così bene). Quindi possono insorgere problemi neanche in casi così isolati. Ne ho visti svariati, anche ad alto livello. Ho fatto l'esempio dello spostare file in giro per il sistema (presumo che qualcuno lo faccia anche con Opensuse) perché è un caso tipico, succede spesso, che i file spostati non vengano acceduti perché hanno le etichette sbagliate a causa dello spostamento.

Dici che la situazione è cambiata, ti ho chiesto come, ma non hai risposto. Vabè fa niente, ho detto che me lo proverò io magari, un giorno, Tuimbleweed con SELinux installato. Ho detto anche che mi auguro che abbiano messo una GUI per gestire policy e contesti. Se hanno una GUI per AppArmor non vedo perché non debbano averne una anche per SEL.

Basta. La motivazione dello switch ancora non mi è chiara, però.

Edit: dimenticavo una cosa; il mio post (tranne per la parte sulle GUI) non si riferisce specificamente all'uso desktop ma in generale (server, desktop). Perché immagino che Suse sia usato anche nei datacenter (tempo fa aveva una partnership con SAP, per es.)

[emanuc]

Basta. La motivazione dello switch ancora non mi è chiara, però.

Da quello che ho capito (non avendo seguito tutta la discussione), la motivazione è che è l'impostazione predefinita su SUSE, anche considerando che SELinux è richiesto in molti contesti aziendali.

[woddy68]

Basta. La motivazione dello switch ancora non mi è chiara, però.

Da quello che ho capito (non avendo seguito tutta la discussione), la motivazione è che è l'impostazione predefinita su SUSE, anche considerando che SELinux è richiesto in molti contesti aziendali.

No, openSUSE non è SUSE e non segue sempre quello che fa SUSE ma a volte si, ci sono mille differenze tra le distribuzioni, forse Leap è simile a SUSE, ma non certo tutte le altre.
La motivazione ufficiale è quella scritta nel comunicato

Il passaggio per installare Selinux per impostazione predefinita sta attraversando l'implementazione e si allinea con la decisione di far crescere l'adozione di Selinux sia per SUSE che per OpenSuse. Si prevede che aumenterà la sicurezza limitando più servizi per impostazione predefinita. Selinux è noto per le sue ricche caratteristiche di sicurezza e l'uso diffuso in ambienti aziendali.

Si prevede che la mossa porterà controlli di accesso più severi a Tumbleweed. Gli utenti possono incontrare bug o problemi, ma i test OpenQA per Tumbleweed hanno svolto un ruolo chiave nell'identificare e risolvere potenziali problemi nella fase di adozione precoce.

I collaboratori sono stati incoraggiati a segnalare eventuali bug che si presentano e possono fare riferimento alla Guida alla segnalazione dei bug Selinux per l'aiuto.

Non è ancora piano per modificare la configurazione del kernel, con l'installatore che gestisce l'attivazione di Selinux su nuove installazioni.

La risposta della comunità a questo cambiamento è stata in gran parte positiva, sebbene alcuni utenti, in particolare quelli che si affidano a profili Apparmor altamente personalizzati, hanno espresso preoccupazione. AppAmor continuerà a essere supportato e gli utenti possono scegliere di installarlo manualmente se lo si desidera.

[emanuc]

Non è che openSUSE ha abbandonato AppArmor in favore di SElinux, è cambiata solo l'impostazione predefinita, ma in fase di installazione con un click puoi abilitare AppArmor.

"Ad oggi, per quanto non mi piaccia, il Kernel engineering sta valutando se abbandonare AppArmor o meno. Potremmo usare qualsiasi caso d'uso per questo.

Abbiamo già condiviso il feedback con il team di Engineering e PM sul fatto che abbiamo una community AppArmor attiva in openSUSE. Tuttavia, il team del kernel afferma che le risorse sono insufficienti per la manutenzione sia di SELinux che delle parti AppArmor nel kernel."

https://code.opensuse.org/leap/features ... mment-3221

[woddy68]

Non è che openSUSE ha abbandonato AppArmor in favore di SElinux, è cambiata solo l'impostazione predefinita, ma in fase di installazione con un click puoi abilitare AppArmor.

"Ad oggi, per quanto non mi piaccia, il Kernel engineering sta valutando se abbandonare AppArmor o meno. Potremmo usare qualsiasi caso d'uso per questo.

Abbiamo già condiviso il feedback con il team di Engineering e PM sul fatto che abbiamo una community AppArmor attiva in openSUSE. Tuttavia, il team del kernel afferma che le risorse sono insufficienti per la manutenzione sia di SELinux che delle parti AppArmor nel kernel."

https://code.opensuse.org/leap/features ... mment-3221

Ho evidenziato quello, perché ad oggi sia AppArmor che SELinux sono supportati, tanto che le vecchie installazioni continuano a usare AppArmor. In futuro chi lo sa... Ovvio che la scelta di SELinux metterà in disparte AppArmor nel lungo periodo.
Oggi ho modificato un file in /usr e non ho avuto problemi...per il momento per il mio caso d'uso va bene SELinux, forse può esserci qualche problema con Samba (che io non uso) o con i giochi, ma i dev. stanno invitando gli utenti a segnalare questi problemi. Si stanno facendo anche test specifici di SELinux in openQA. Vedremo....

[emanuc]

Ma avrebbe comunque senso, perché le risorse non sono illimitate. Sono dell'idea che, con risorse limitate, si debba supportare ciò che si riesce a mantenere bene. Anche per questo sono a favore di Flatpak: così le risorse vengono condivise e non duplicate.

[woddy68]

Ma avrebbe comunque senso, perché le risorse non sono illimitate. Sono dell'idea che, con risorse limitate, si debba supportare ciò che si riesce a mantenere bene. Anche per questo sono a favore di Flatpak: così le risorse vengono condivise e non duplicate.

In openSUSE non funziona così, se c'è parte della community disposta a mantenerlo, lo faranno a prescindere da SUSE.
In ogni caso, anche ammesso che venga abbandonato, ci vorrà ancora molto tempo, perché comunque le vecchie installazioni continueranno a usare AM, molti hanno profili personalizzati ecc., non è una cosa che puoi fare dall' oggi a domani.
Ma si...per il resto concordo.
Da quel che so , anche i flatpak hanno una sicurezza più robusta con SL.

[woddy68]

Questo credo sia un buon risultato...https://www.phoronix.com/news/openSUSE- ... e-Build-RB

[emanuc]

Basta. La motivazione dello switch ancora non mi è chiara, però.

Da quello che ho capito (non avendo seguito tutta la discussione), la motivazione è che è l'impostazione predefinita su SUSE, anche considerando che SELinux è richiesto in molti contesti aziendali.

Abbiamo una risposta da uno sviluppatore di SUSE. In conclusione AppArmor sembra più flessibile e facile da gestire ma nella pratica è meno sicuro perché non tutte le APP hanno delle policy, finendo con un sistema non totalmente sicuro/blindato. SELinux è più sicuro ma anche più oneroso da mantenere per gli sviluppatori.

Non è più performante, ma è probabilmente più efficace

Il vantaggio più grande di AppArmors è che è progettato in modo tale da poter avere policy separate per diversi servizi/app/processi

La teoria è quindi che un pacchetto potrebbe contenere il suo profilo AppArmor corrispondente che verrebbe aggiornato con il software

La pratica, tuttavia, è che questo non accade molto spesso, lasciando un profilo di sicurezza molto discontinuo in cui alcune cose beneficiano di AppArmor e molte altre no.

Non è un bell'aspetto per nessuno strumento di sicurezza: sarebbe come avere serrature solo sulle porte dei quartieri ad alto tasso di criminalità o firewall che, per progettazione, funzionano solo per proteggere porte specifiche se il software lo richiede espressamente, altrimenti tutte le porte sono aperte.

SELinux d'altro canto ha una politica unica per l'intero sistema che tutti ottengono e che etichetta tutti i tuoi file e li protegge di conseguenza

È molto più lavoro per il nostro team di sicurezza da mantenere... ma lo fanno in silenzio da anni, dopotutto MicroOS, Aeon e altri sono stati SELinux solo per un bel po' di tempo ormai

Quindi... in poche parole, è più sicuro, in senso pratico, fare qualcosa in modo coerente in tutto il sistema

Fonte

[woddy68]

Beh dai non c'era bisogno di disturbare un dev di SUSE, lo sanno tutti che SELinux è più sicuro di AppArmor.
Il punto credo che sia un' altro...ovvero fare in modo che l' utente medio non si imbatta in problemi causati dalle restrizioni di SL.
Le distro che usano AppArmor caricano pochissimi profili, il che lo rendono quasi inutile.
Diverso il discorso per Ubuntu e le app snap, perché queste necessitano tutte di un profilo.

[woddy68]

In merito ad una mia domanda o aspettativa

Mi piace SELinux perché secondo me offre più sicurezza di AM, tuttavia l'ideale sarebbe che funzionasse come in Android. Cioè avere un sistema che chiede all'utente se dare o meno un permesso. Speriamo che prima o poi ci si arrivi. Devo dire che nella mia esperienza SELinux non mi ha creato problemi, ma non uso quella roba di wine&co.

Mi ha risposto un dev di openSUSE responsabile di KDE

setroubleshootdè è almeno un passo in quella direzione.

[woddy68]

Il team di sicurezza di openSUSE ha finalmente accettato kio-admin in openSUSE.
Qui, la lunga spiegazione https://security.opensuse.org/2025/02/2 ... tance.html

[frapox]

molto male l' installer di OpenSuse Tumbleweed.

Premessa: inizialmente optato per la ISO "Network Image". Fa il boot, inizializza i driver e la rete, poi lancia la fase grafica dell'installer ma... lo schermo è quasi del tutto nero. Si vede che c'è qualcosa ma la luminosità è bassissima e non si riesce a regolare. Insomma ho dovuto scaricarmi l'Offline installer, che invece arriva regolarmente alla fase grafica. Però poi, una volta arrivati al partizionamento dischi:

• non consente di riusare i subvol Btrfs esistenti (volevo riusare home),
• non controlla lo spazio disponibile nelle partizioni
  - /boot/efi non aveva abbastanza spazio per ospitare i kernel ma lui non si è accorto
  - non ha creato una partizione /boot per sopperire al problema, o riusato l'esistente
• non consente di ridimensionare le partizioni neanche in modalità esperto,
• dopo l'install stampa l'errore dello spazio mancante e riavvia il sistema come se nulla fosse
  - non avverte che l'installazione è fallita,
  - non dà possibilità di recupero

Insomma riavvia e non c'e neanche la voce di menù per fare il boot di Opensuse (si vede che ha installato sd-boot ma non i kernel).

L'unica cosa buona è che imposta i subvolume automaticamente per gli snapshot automatici. Però... almeno per il mio caso d'uso l'installer di Fedora è nettamente superiore.

Edit.
https://www.reddit.com/r/openSUSE/comme ... s_default/
https://lists.opensuse.org/archives/lis ... SVBQDFIOP/

Quelli di OpenSuse hanno sostituito Grub2 con systemd-boot che richiede una /boot/efi (ESP) "grossa" (1-2 GB) per accogliere i kernel... Morale: se hai una ESP piccola (perché te l'ha creata Windows così) con UN kernel te la satura tutta e non c'è spazio per futuri kernel.

Soluzione: siccome la ESP è in vfat, Gparted non riesce a ridimensionare il filesystem contenuto nella partizione. Ho dovuto distruggerla/ricrearla della dimensione adeguata. A questo punto è possibile rilanciare l'installer di Tumbleweed, col partizionamento avanzato mappare /boot/efi nella nuova ESP, e impostare la root con i subvolume (li crea in automatico).

Morale: se installate "clean" su un nuovo sistema, tenetevi una ESP di almeno un GB (ma anche di più spazio permettendo, sopratutto per install multi-OS).

Nota: la specifica BLS (seguita da sd-boot e altri bootloader "next gen") prevede anche una partizione "extended boot" (XBOOTLDR) che può essere mappata per esempio sotto /boot, così sarebbe possibile riusare una ESP senza distgruggerla. I problemi con questa config sono due: 1) l'installer di OpenSuse non consente di installare sd-boot "dicendogli" di usare la XBOOTLDR; 2) serve uno script che a ogni aggiornamento del kernel, mette il kernel nella posizione giusta (sotto /boot appunto e non sotto /boot/efi) e io non so se allo stato attuale Tumbleweed ce l'abbia (presumo di no).

Quindi, alla fine ho optato per "tutto in ESP". Comunque senza /boot separata ho praticamente una Full Disk Encryption, gestita da sd-boot anziché Grub, con gli snapshot automatici. non male!