{"id":20284,"date":"2026-08-03T11:50:45","date_gmt":"2026-08-03T09:50:45","guid":{"rendered":"https:\/\/webhosting.de\/linux-capabilities-root-rechte-granular-aufteilen-sicherheitskonzept\/"},"modified":"2026-08-03T11:50:45","modified_gmt":"2026-08-03T09:50:45","slug":"capacita-di-linux-diritti-di-root-ripartizione-granulare-concetto-di-sicurezza","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-capabilities-root-rechte-granular-aufteilen-sicherheitskonzept\/","title":{"rendered":"Funzionalit\u00e0 di Linux: assegnazione sicura e granulare dei privilegi di root"},"content":{"rendered":"<p>Con le funzionalit\u00e0 di Linux, suddivido i diritti di root in privilegi piccoli e chiaramente definiti, riducendo cos\u00ec drasticamente il rischio. In questo modo controllo in modo mirato quali processi possono eseguire azioni particolari e limito la superficie di attacco di ogni applicazione.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>A grana fine<\/strong> anzich\u00e9 essere onnipotenti: suddividere i diritti di root in privilegi pi\u00f9 specifici.<\/li>\n  <li><strong>Funzionalit\u00e0 dei file<\/strong> anzich\u00e9 Set-UID: associare i diritti necessari direttamente ai file binari.<\/li>\n  <li><strong>Insiemi di capacit\u00e0<\/strong> Configurare in modo mirato: Permitted, Effective, Inheritable, Bounding.<\/li>\n  <li><strong>Separazione dei privilegi<\/strong>: Separare rigorosamente servizi, strumenti e attivit\u00e0.<\/li>\n  <li><strong>La difesa in profondit\u00e0<\/strong>: Integrare le funzionalit\u00e0 con sudo, i ruoli e i protocolli.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-serververwaltung-8291.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 separare i privilegi di root?<\/h2>\n\n<p>Un account root consente <strong>Accesso completo<\/strong> a livello di file e processi, ma \u00e8 proprio questo che pu\u00f2 portare a errori dalle gravi conseguenze. Basta un comando errato o un exploit e l\u2019intera installazione va in tilt. Limito quindi le operazioni di ampia portata allo stretto necessario, riducendo cos\u00ec l\u2019entit\u00e0 dei danni e i tempi di ripristino. Il principio dei privilegi minimi mantiene i servizi snelli e controllabili. Disattivo l\u2019accesso diretto come root, mi affido ai ruoli e registro log completi.<\/p>\n\n<h2>Le funzionalit\u00e0 di Linux spiegate in breve<\/h2>\n\n<p>Le \"capabilities\" di Linux suddividono i classici privilegi di root in categorie ben definite <strong>Privilegi<\/strong>. Ogni processo riceve solo i moduli di cui ha effettivamente bisogno per svolgere il proprio compito, come ad esempio il binding alle porte inferiori a 1024 o l\u2019invio di segnali specifici. In questo modo si evita il precedente approccio \u201ctutto o niente\u201d. Il kernel gestisce questi moduli per ogni singolo processo e li applica in modo rigoroso. In questo modo il controllo rimane granulare e tracciabile.<\/p>\n\n<p>Dal punto di vista tecnico, collego le competenze a <strong>Processi<\/strong> (tramite i loro set di capacit\u00e0) oppure a <strong>File<\/strong> (come attributi estesi <code>security.capability<\/code> ai file binari ELF). Nel caso del <code>execve()<\/code>All'avvio, il kernel unisce le capacit\u00e0 dei file con i set dei processi: in parole povere, le capacit\u00e0 consentite derivanti dall'attributo del file, insieme ai diritti ereditabili dal processo chiamante, vengono combinate nel nuovo set \"Permitted\" e \u2013 se contrassegnate come tali \u2013 attivate contemporaneamente nel set \"Effective\". Ci\u00f2 evita le deviazioni Set-UID e mantiene i privilegi visibili e verificabili.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_rechte_besprechung_3820.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendere i set di capacit\u00e0 nel contesto dei processi<\/h2>\n\n<p>Ogni processo dispone di diverse categorie di diritti, che io utilizzo in modo mirato <strong>controllo<\/strong>. Il Permitted-Set definisce ci\u00f2 che un processo pu\u00f2 possedere in linea di principio. L'Effective-Set stabilisce ci\u00f2 che \u00e8 attualmente attivo. L'Inheritable-Set regola quali privilegi possono essere trasferiti ai processi figli. Il Bounding-Set fissa un limite massimo rigido e impedisce ai processi di superarlo.<\/p>\n\n<h2>Funzionalit\u00e0 ambientali e Securebits<\/h2>\n\n<p>Oltre ai set gi\u00e0 noti, c'\u00e8 il <strong>Set ambient<\/strong>, che presso il <code>execve()<\/code> non scade automaticamente. Lo utilizzo quando un processo senza privilegi necessita in modo mirato di diritti minimi su pi\u00f9 <code>eseguire<\/code>-dovrebbe ignorare i livelli (ad esempio quando si richiamano programmi di supporto esterni). I diritti \"ambient\" vengono inclusi nei diritti effettivi solo se il file richiamato non imposta a sua volta alcuna \"file capability\": in questo modo evito un'escalation indesiderata.<\/p>\n\n<p>Con i <strong>Securebits<\/strong> gestisco i dettagli delle transizioni, ad esempio se un processo, dopo il cambio di UID, possa mantenere le capacit\u00e0 precedentemente impostate (<code>keepcaps<\/code>) oppure se, in linea di principio, non gli sia consentito ottenere nuovi privilegi (<code>no_new_privs<\/code>). Nella pratica, impiego Securebits in modo rigoroso e rinuncio alla comodit\u00e0 per interrompere le catene di exploit.<\/p>\n\n<h2>File Capabilities al posto di Set-UID<\/h2>\n\n<p>Sostituisco i file binari con Set-UID con le funzionalit\u00e0 dei file per ridurre il rischio di <strong>abbassare<\/strong>. Anzich\u00e9 assegnare i privilegi di root a un programma, mi limito a impostare i diritti necessari. Una modifica tipica si presenta cos\u00ec: <code>setcap 'cap_net_bind_service=+ep' \/usr\/bin\/meinserver<\/code>. Con <code>getcap -r \/<\/code> verifico quali file contengono le competenze. Ci\u00f2 riduce sensibilmente i percorsi di escalation.<\/p>\n\n<p>\u00c8 importante che le funzionalit\u00e0 dei file si applichino solo a <strong>File binari ELF<\/strong> funzionano. Gli script dell\u2019interprete (ad es. Python, Bash) non li ereditano in modo affidabile. In questi casi, incapsulo l\u2019azione privilegiata in un piccolo programma di supporto verificato staticamente oppure utilizzo la socket activation, in modo che il mio servizio non debba effettuare il binding autonomamente. Inoltre, tengo sotto controllo i permessi dei file: le capabilities conferiscono diritti speciali nei confronti del kernel, ma sostituiscono <strong>nessuno<\/strong> ACL standard o permessi POSIX.<\/p>\n\n<p>Durante la copia o la compressione, le competenze si perdono rapidamente: <code>cp<\/code> senza supporto XATTR, impostazione errata <code>umask<\/code> oppure rimuovere un artefatto di build da un file system privo di attributi estesi <code>security.capability<\/code> senza dirlo. Per questo motivo lavoro in modo riproducibile e utilizzo: <code>cp --preserve=xattr ...<\/code>, <code>tar --xattrs<\/code>, <code>rsync -X<\/code>. Nelle build dei pacchetti imposto esplicitamente le funzionalit\u00e0 dei file nello script di installazione, provo l'installazione in una macchina virtuale pulita e verifico <code>getcap<\/code> nel CI.<\/p>\n\n<h2>Separazione dei privilegi con scenari realistici<\/h2>\n\n<p>Un server web necessita dell'accesso alle porte 80\/443, ma non ai moduli del kernel n\u00e9 ai riavvii del sistema, pertanto imposto <strong>CAP_NET_BIND_SERVICE<\/strong> e nient\u2019altro. Un agente di backup pu\u00f2 leggere e scrivere file, ma non pu\u00f2 modificare la configurazione di rete. Uno strumento di monitoraggio dispone di diritti di lettura sugli indicatori, ma non ha diritti di modifica. Queste limitazioni confinano gli attacchi a livello locale, impedendo loro di avere ripercussioni su tutto il sistema. \u00c8 proprio questa separazione a rendere i servizi gestibili e a tenere sotto controllo le configurazioni errate.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/balancing-linux-capabilities-5618.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Combinare con sudo e i ruoli<\/h2>\n\n<p>Le funzionalit\u00e0 non sostituiscono un codice pulito <strong>Struttura dei ruoli<\/strong>, le integrano. Concedo i diritti sudo con molta cautela, utilizzo percorsi di comando completi e mi tengo alla larga da regole generiche come \u201eALL=(ALL) ALL\u201c. Ogni autorizzazione viene registrata. I gruppi raggruppano le responsabilit\u00e0, mentre le capacit\u00e0 stabiliscono limiti tecnici nei processi. In questo modo si creano competenze chiare senza privilegi eccessivi.<\/p>\n\n<h2>Insidie comuni e buone pratiche<\/h2>\n\n<ul>\n  <li><strong>Non utilizzare CAP_SYS_ADMIN come abbreviazione:<\/strong> Questo diritto \u00e8 un concetto generico. Lo sostituisco con alternative pi\u00f9 specifiche (ad es. <code>CAP_SYS_CHROOT<\/code>, <code>CAP_SYS_TIME<\/code>, <code>CAP_SYS_NICE<\/code>) oppure rinuncia del tutto.<\/li>\n  <li><strong>I diritti sui file rimangono rigorosamente in vigore:<\/strong> Le funzionalit\u00e0 non disattivano il DAC in modo generale. Senza <code>CAP_DAC_OVERRIDE<\/code> Il kernel continua a rispettare i bit di propriet\u00e0 e di modalit\u00e0. Continuo quindi ad assegnare i diritti di lettura in misura minima.<\/li>\n  <li><strong>Indurimento del percorso:<\/strong> Se assegno delle funzionalit\u00e0 di file a un file binario, impedisco lo spoofing del PATH (percorsi assoluti in <code>sudoers<\/code>, diritti di scrittura disabilitati sulle directory presenti nel percorso di ricerca).<\/li>\n  <li><strong>Pubblica presto, pubblica spesso:<\/strong> I processi potrebbero avviarsi con pi\u00f9 diritti del necessario. Rimuovo le autorizzazioni superflue subito dopo l'operazione delicata (<code>prctl()<\/code>\/libcap) e imposta <code>no_new_privs<\/code>, ove possibile.<\/li>\n  <li><strong>Limitare l'ereditariet\u00e0:<\/strong> Mantengo ridotti i set \u201cInheritable\u201d e \u201cAmbient\u201d. I processi figli non devono aprire nuove porte.<\/li>\n  <li><strong>Verifica della pipeline di compilazione e distribuzione:<\/strong> Confermo che <code>security.capability<\/code> venga mantenuto e che nessuna fase di staging (livelli dei container, NFS, scanner di artefatti) rimuova gli XATTR.<\/li>\n<\/ul>\n\n<h2>Panoramica delle principali capacit\u00e0 e dei rischi<\/h2>\n\n<p>Prima di assegnare i privilegi, definisco chiaramente quelli necessari e ne valuto il rischio. La tabella seguente mostra alcuni esempi tipici con le relative conseguenze e classificazione. Prendo sempre in considerazione delle alternative per evitare di concedere diritti eccessivi. Soprattutto <strong>CAP_SYS_ADMIN<\/strong> Li concedo con estrema parsimonia. Ove possibile, sostituisco i privilegi di ampia portata con varianti mirate e circoscritte.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Capacit\u00e0<\/th>\n      <th>Scopo<\/th>\n      <th>Il rischio<\/th>\n      <th>Esempio<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CAP_NET_BIND_SERVICE<\/td>\n      <td>Assegnare le porte inferiori a 1024<\/td>\n      <td>Da basso a medio<\/td>\n      <td>Server web sulle porte 80\/443<\/td>\n    <\/tr>\n    <tr>\n      <td>CAP_SYS_BOOT<\/td>\n      <td>Riavvia il sistema<\/td>\n      <td>Alto<\/td>\n      <td>Riavvio programmato<\/td>\n    <\/tr>\n    <tr>\n      <td>CAP_SYS_MODULE<\/td>\n      <td>Caricare\/rimuovere i moduli del kernel<\/td>\n      <td>Molto alto<\/td>\n      <td>Gestione dei driver<\/td>\n    <\/tr>\n    <tr>\n      <td>CAP_SYS_ADMIN<\/td>\n      <td>Operazioni amministrative versatili<\/td>\n      <td>Molto alto<\/td>\n      <td>Varie attivit\u00e0 di manutenzione<\/td>\n    <\/tr>\n    <tr>\n      <td>CAP_SETUID \/ CAP_SETGID<\/td>\n      <td>Cambia UID\/GID<\/td>\n      <td>Medio-alto<\/td>\n      <td>Cambio di mansioni durante il servizio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_capabilities_tech-office_4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>Oltre alla tabella, sto valutando proprio ora <code>CAP_SYS_PTRACE<\/code> (debug dei processi), <code>CAP_NET_ADMIN<\/code> (parametrizzazione della rete) e <code>CAP_DAC_OVERRIDE<\/code> (aggirare le restrizioni di accesso ai file) \u00e8 una pratica estremamente criticabile. Spesso esistono modelli che consentono di evitare tali restrizioni: endpoint dedicati per le metriche anzich\u00e9 lo \u201csnooping\u201d dei processi, l\u2019attivazione dei socket o il reindirizzamento delle porte anzich\u00e9 i diritti di bind e diritti sui file ben definiti anzich\u00e9 un aggiramento generico del DAC.<\/p>\n\n<h2>Hardening nei container e nell'hosting<\/h2>\n\n<p>Negli ambienti multi-tenant ritengo che le competenze debbano essere radicalmente <strong>piccolo<\/strong> e impedisco l'ereditariet\u00e0 nei processi figli. I container traggono notevoli vantaggi non appena il bounding set \u00e8 ben definito. Combino questo approccio con spazi isolati per il filesystem e i processi. Per avere una panoramica degli approcci di isolamento, trovo utile questa introduzione a <a href=\"https:\/\/webhosting.de\/it\/processo-isolamento-hosting-chroot-cagefs-container-jails-sicurezza-confronto\/\">Isolamento dei processi<\/a>. In questo modo i servizi rimangono separati, anche se un'applicazione presenta dei problemi.<\/p>\n\n<p>In pratica, imposto i contenitori di default su \u201erimuovi tutto, aggiungi in modo selettivo\u201c: <code>--cap-drop=ALL --cap-add=NET_BIND_SERVICE<\/code> per i servizi web, nessun diritto di montaggio, nessun <code>SYS_ADMIN<\/code>. Negli ambienti orchestrati mantengo il profilo in primo piano e lo verifico nelle policy. Importante: non mi affido alle funzionalit\u00e0 dei file presenti nell'immagine, ma assegno i diritti in fase di esecuzione nell'Orchestrator \u2013 in modo riproducibile e verificabile.<\/p>\n\n<h2>Interazione con SELinux e AppArmor<\/h2>\n\n<p>Le funzionalit\u00e0 determinano ci\u00f2 che un processo \u00e8 autorizzato a fare, mentre i profili MAC definiscono a cosa pu\u00f2 accedere, e le due cose sono in armonia tra loro <strong>buono<\/strong>. Definisco le capabilities in modo restrittivo e lascio che SELinux o AppArmor limitino l'accesso a file e socket. In questo modo si crea una protezione a pi\u00f9 livelli che pone diversi ostacoli agli exploit. Trovo un rapido confronto qui: <a href=\"https:\/\/webhosting.de\/it\/selinux-vs-apparmor-sicurezza-linux-rafforzamento-dei-server-protezione\/\">SELinux vs. AppArmor<\/a>. In questo modo, un servizio compromesso rimane isolato e pu\u00f2 causare meno danni.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_schreibtisch2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pratica: procedere passo dopo passo<\/h2>\n\n<p>Inizier\u00f2 con un'analisi della situazione attuale di tutti i servizi e delle loro <strong>Requisiti<\/strong>. Successivamente, rimuovo i file binari Set-UID non necessari o li sostituisco con file capabilities mirate. Configuro `sudo` in modo restrittivo e documento ogni voce. Assegno i compiti a ruoli e gruppi, mantenendo i diritti al minimo. Successivamente eseguo dei test sotto carico e controllo le voci di log alla ricerca di rifiuti imprevisti.<\/p>\n\n<p>Una breve lista di controllo mi aiuta nella transizione:<\/p>\n<ul>\n  <li>Definire per iscritto i requisiti per ciascun servizio (solo ci\u00f2 che \u00e8 realmente necessario).<\/li>\n  <li>Fare un inventario dei diritti speciali esistenti (<code>find \/ -perm -4000<\/code>, <code>getcap -r \/<\/code>).<\/li>\n  <li>Sostituire in modo mirato: eliminare il Set-UID, impostare le funzionalit\u00e0 dei file, revocare i diritti tempestivamente.<\/li>\n  <li>Chiudere le ereditazioni: ottimizzare il bounding set, ridurre al minimo Inheritable\/Ambient.<\/li>\n  <li>Proteggere i profili systemd\/container (<code>CapabilityBoundingSet=<\/code>, <code>NoNewPrivileges=yes<\/code>).<\/li>\n  <li>Eseguire test sotto carico, verificare i log e le voci di audit, documentare le eccezioni.<\/li>\n<\/ul>\n\n<h2>Monitoraggio, spazi dei nomi e audit continui<\/h2>\n\n<p>Controllo i file di log, gli allarmi e le chiamate di sistema, in modo che le azioni indesiderate vengano immediatamente <strong>distinguersi<\/strong>. Verifico regolarmente le modifiche apportate alle funzionalit\u00e0, alle regole di sudo e ai ruoli. Laddove opportuno, isolo ulteriormente i carichi di lavoro tramite i meccanismi di isolamento del kernel. Questa panoramica offre un buon punto di partenza per <a href=\"https:\/\/webhosting.de\/it\/contesto-server-isolamento-spazi-dei-nomi-cgroups-hosting-sicurezza\/\">Spazi dei nomi e cgroup<\/a>. In questo modo riesco a individuare tempestivamente eventuali anomalie e a mantenere pulito l'ambiente circostante.<\/p>\n\n<p>Nella vita di tutti i giorni ricorro a semplici verifiche: <code>capsh --print<\/code> mi mostra l'attuale set di abilit\u00e0, <code>getpcaps<\/code> elenca i diritti processuali e in <code>\/proc\/\/status<\/code> leggo <code>CapEff<\/code>, <code>CapPrm<\/code>, <code>CapBnd<\/code>. Con <code>auditd<\/code> tengo traccia delle modifiche allo stato delle capacit\u00e0 (ad es. regola su <code>capset<\/code>), metto in correlazione gli eventi con le distribuzioni e imposto degli allarmi qualora dovessero comparire improvvisamente diritti di accesso estesi. Nei casi pi\u00f9 complessi, mi aiuta <code>strace -e capget,capset<\/code>, per rendere visibili le manipolazioni dei diritti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-capabilities-8123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Esempi pratici su systemd e container<\/h2>\n\n<p>Gestisco molti servizi come unit\u00e0 systemd e vi incapsulo i permessi:<\/p>\n<ul>\n  <li><code>CapabilityBoundingSet=CAP_NET_BIND_SERVICE<\/code> riduce la finestra dei diritti accessibili allo stretto necessario.<\/li>\n  <li><code>AmbientCapabilities=CAP_NET_BIND_SERVICE<\/code> conferisce al servizio il diritto di collegarsi alle porte 80\/443 senza file capabilities.<\/li>\n  <li><code>NoNewPrivileges=yes<\/code> impedisce successive estensioni dei diritti.<\/li>\n  <li><code>Utente=<\/code>, <code>Gruppo=<\/code>, <code>ProtectSystem=strict<\/code>, <code>PrivateTmp=yes<\/code> completano l'isolamento.<\/li>\n<\/ul>\n<p>Nei container avvio i processi in modo il pi\u00f9 snello possibile: <code>docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE --read-only<\/code>. Per i processi di breve durata utilizzo le funzionalit\u00e0 di durata anzich\u00e9 quelle relative ai file nell'immagine, in modo che le build rimangano riproducibili e i diritti siano legati all'ambiente.<\/p>\n\n<h2>Esempi concreti di migrazione tratti dalla pratica<\/h2>\n\n<ul>\n  <li><strong>ping senza Set-UID:<\/strong> Invece <code>setuid root<\/code> metto <code>setcap 'cap_net_raw=+ep' \/bin\/ping<\/code>. In questo modo ogni utente pu\u00f2 aprire socket ICMP senza disporre dei pieni diritti di root. Controllo regolarmente con <code>getcap \/bin\/ping<\/code>, se l'attributo \u00e8 stato conservato.<\/li>\n  <li><strong>Servizio web sulle porte 80\/443:<\/strong> Eseguo il mio servizio come utente senza privilegi e inserisco solo <code>cap_net_bind_service<\/code>. Se il servizio \u00e8 comunque collegato a un proxy inverso, in alternativa posso anche collegarlo alle porte 80\/443 e utilizzare internamente una porta alta, senza bisogno di competenze aggiuntive.<\/li>\n  <li><strong>Cambio di parti nel procedimento:<\/strong> Per gli strumenti che richiedono temporaneamente privilegi pi\u00f9 elevati (ad esempio per impostare i livelli di priorit\u00e0), imposto <code>cap_sys_nice<\/code>, esegui l'azione in anticipo e poi disattiva l'abilit\u00e0. Evito di mantenere i privilegi aumentati in modo permanente.<\/li>\n<\/ul>\n\n<h2>Limiti e alternative<\/h2>\n\n<p>Non tutti i casi d'uso richiedono l'uso delle funzionalit\u00e0. Spesso esistono alternative sicure che comportano un rischio minore:<\/p>\n<ul>\n  <li><strong>Attivazione della presa:<\/strong> Il servizio di avvio (ad es. systemd) apre dei socket con privilegi e li passa al processo. In questo modo, il mio servizio non ha bisogno dei diritti di bind.<\/li>\n  <li><strong>Reindirizzamento delle porte:<\/strong> Tramite le regole del firewall reindirizzo le porte 80 e 443 su una porta alta. Il servizio rimane senza privilegi e il comportamento del sistema non subisce alcuna modifica.<\/li>\n  <li><strong>Porte low non privilegiate:<\/strong> Laddove opportuno, posso aumentare la soglia per le porte non privilegiate. Ci\u00f2, per\u00f2, amplia il margine di manovra per tutti i processi: valuto attentamente il rapporto tra rischio e praticit\u00e0.<\/li>\n  <li><strong>Piccoli aiutanti anzich\u00e9 tuttofare:<\/strong> Meglio un file binario minuscolo e verificato con una sola funzionalit\u00e0 che un enorme monolite con un ampio catalogo di diritti.<\/li>\n<\/ul>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Con <strong>Funzionalit\u00e0 di Linux<\/strong> Suddivido i poteri di root in privilegi pi\u00f9 piccoli e facilmente gestibili. Le \u201cfile capabilities\u201d sostituiscono i rischiosi binari Set-UID e riducono le conseguenze di un attacco. In combinazione con regole sudo rigorose, ruoli e profili MAC, si crea una protezione a pi\u00f9 livelli con confini ben definiti. I set \u00abBounding\u00bb e \u00abInheritable\u00bb limitano l\u2019ereditariet\u00e0 e mantengono i processi in linea con le direttive. Chi adotta questo approccio riduce sensibilmente la superficie di attacco e mantiene gestibile il carico amministrativo.<\/p>","protected":false},"excerpt":{"rendered":"<p>Le capacit\u00e0 di Linux suddividono i diritti di root in privilegi granulari. Scoprite come il modello delle capacit\u00e0 rafforza la sicurezza dei vostri server e consente la separazione dei privilegi sui sistemi Linux.<\/p>","protected":false},"author":1,"featured_media":20277,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20284","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"93","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux Capabilities","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20277","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20284","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20284"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20284\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20277"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20284"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20284"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20284"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}