Linux Capabilities - ita - v2.1.5 - compatta

Linux Capabilites
Indice
Titolo Pagine Titolo Pagine
Indice 1 Estrazione/Decodifica... 4
Diritti 1 File di configurazione 2
LC: cosa sono e... 3 Assegnazione delle cap. 10
Il caso di ping 4 Stato di alcune distribuz. 7
Quale LC per ping? 3 Problemi? 2
Gestione delle LC 4 Ringraziamenti 1
Altri esempi 10

DDiirriittttii
Presentazione di: Alessandro Selli <alessandroselli@linux.com>
Copyright © 2014 Alessandro Selli.
Si concede il permesso di effettuare copie, di distribuire e/o di
modificare di questo documento secondo quanto stabilito nella licenza
GNU Free Documentation License, versione 1.3 o successiva
pubblicata dalla Free Software Foundation, stante la presente
diapositiva (numero 2) quale Sezione Invariante e nessun testo di
prima o di quarta di copertina.
Una copia della licenza è disponibile in linea come pure presso
l'autore.
Versione 2.1.5, 2014/10/27

Linux Capabilites:
cosa sono e fanno 1-3
● Inizialmente implementavano POSIX:
 1003.1e (API), "Protection, Audit and
Control Interfaces"
 1003.2c (Shell and Utilities), "Protection
and Control Interfaces"
●Detti infatti a volte Linux POSIX Capabilities
●Ultima revisione di 1003.1e e 1003.2c nel 1997
●Nel 1999 sono stati dichiarati bozze ritirate
● Linux è quindi andato per la sua strada

Linux Capabilites:
Vantaggi:
● Permettono la delega di diritti di superutente a
processi non privilegiati, come il bit suid
● Sono registrati sul filesystem, come il bit suid
● Non funzionano sul principio “o tutto o nulla”,
diversamente dal bit suid
In breve:
● permettono ad un processo di fare alcune cose
con i privilegi di root, ma null'altro

Linux Capabilites:
Svantaggi:
● I comandi necessitano di codice LC specifico
● Alcuni FS non supportano LC (NFS v.3, ma squashfs,
tmpfs e f2fs adesso si):
[root@debian ~]# getcap /mnt/nfs/nfsserver/dumpdates
Failed to get capabilities of file `/mnt/nfs/nfsserver/dumpdates'
(Operation not supported)
[root@debian ~]#
● I privilegi LC non sono ridotti come il SUID root
 Ma le recenti libcap-ng rendono facile farlo

IIll ccaassoo ddii ppiinngg 11--44
● Un esempio classico: ping
● Ha bisogno dei diritti di superutente per inviare
pacchetti ICMP di tipo echo-request
● Nessuno vorrebbe permettere a chiunque di
produrre pacchetti ICMP arbitrari!
● L'approccio tradizionale è il seguente:

Situazione iniziale:
[alessandro@ubuntu ~]$ lsb_release drc
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
[alessandro@ubuntu ~]$ ll /bin/ping
rwsrxrx
1 root root 44178 mag 7 23:51 /bin/ping
[alessandro@ubuntu ~]$ ping c
3 routeadd.
net
PING routeadd.
net (195.182.210.166) 56(84) bytes of data.
64 bytes from routeadd.
net (195.182.210.166): icmp_seq=1 ttl=55 time=46.8 ms
routeadd.
net ping statistics 3
packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 45.549/46.329/46.829/0.558 ms
[alessandro@ubuntu ~]$

● Secondo gli standard i diritti del processo sono
quelli dell'utente che ha lanciato l'eseguibile
Non del proprietario del file eseguibile!
● A meno che il bit suid bit non sia impostato.
rwsrxrx

“Sabotiamo” ping:
[root@ubuntu ~]# chmod us
/bin/ping
[root@ubuntu ~]# ll /bin/ping
rwxrxrx
[root@ubuntu ~]#
Conseguenza:
3 routeadd.
net
ping: icmp open socket: Operazione non permessa
Se non specificato diversamente, Ubuntu = Fedora.

QQuuaallee LLCC ppeerr ppiinngg?? 11--33
● Vogliamo tanto i privilegi quanto la sicurezza
● Vogliamo poter creare socket ICMP senza
assumere tutti I privilegi di root!
● Come ci aiutano le Linux Capabilities?
● RTFM, ovviamente!
➢ man capabilities(7)
➢ Lista & informazioni più aggiornate:
linux/include/uapi/linux/capability.h

Ci sono molte capability tra cui scegliere:
AUDIT_CONTROL AUDIT_WRITE BLOCK_SUSPEND CHOWN DAC_OVERRIDE DAC_READ_SEARCHC
AP_LEASE
FOWNER FSETID IPC_LOCK IPC_OWNER KILL LEASE
LINUX_IMMUTABLE MAC_ADMIN MAC_OVERRIDE MKNOD NET_ADMIN NET_BIND_SERVICE
Questa è quella che ci serve
NET_RAW SETGID SETFCAP SETPCAP SETUID SYS_ADMIN
SYS_BOOT SYS_CHROOT SYS_MODULE SYS_NICE SYS_PACCT SYS_PTRACE
SYS_RAWIO SYS_RESOURCE SYS_TIME SYS_TTY_CONFIG SYSLOG WAKE_ALARM

Ci sono molte capability tra cui scegliere:
AUDIT_CONTROL AUDIT_WRITE BLOCK_SUSPEND CHOWN DAC_OVERRIDE DAC_READ_SEARCHC
AP_LEASE
Il CAP_ iniziale è sato omesso nei nomi
FOWNER FSETID IPC_LOCK IPC_OWNER KILL LEASE
LINUX_IMMUTABLE MAC_ADMIN MAC_OVERRIDE MKNOD NET_ADMIN NET_BIND_SERVICE
Questa è quella che ci serve
NET_RAW SETGID SETFCAP SETPCAP SETUID SYS_ADMIN
SYS_BOOT SYS_CHROOT SYS_MODULE SYS_NICE SYS_PACCT SYS_PTRACE
SYS_RAWIO SYS_RESOURCE SYS_TIME SYS_TTY_CONFIG SYSLOG WAKE_ALARM

Il manuale dice:
CAP_NET_RAW
* use RAW and PACKET sockets;
* bind to any address for transparent proxying.
Sembra quella che ci serve.
Come la usiamo?

GGeessttiioonnee ddeellllee LLCC 11--44
Le capability sono gestite con i comandi:
➢ getcap, mostra le capability dei file
➢ setcap, imposta le capability ai file
➢ getpcaps, mostra le cap. dei processi
➢ capsh, capability shell wrapper
Ciascuna capability può essere associata ai set:
➢ p, al processo è permessa la capability
➢ e, la capability è resa effettiva
➢ i, la capab. è ereditata dopo un execve()

Le capability sono gestite con i comandi:
➢ getcap, mostra le capability dei file
➢ setcap, imposta le capability ai file
➢ getpcaps, mostra le cap. dei processi
➢ capsh, capability shell wrapper
Ciascuna capability può essere associata ai set:
➢ p, al processo è permessa la capability
➢ e, la capability è resa effettiva
➢ i, la capab. è ereditata dopo un execve()
Questa è diventata un bit

Iniziamo ad usarle:
/bin/ping
rwxrxrx
1 root root 44168 mag 7 23:51 /bin/ping*
[root@ubuntu ~]# getcap /bin/ping
[root@ubuntu ~]# setcap CAP_NET_RAW=ep /bin/ping
Maiuscole o minuscole
Sempre minuscole!

Iniziamo ad usarle:
/bin/ping
rwxrxrx
1 root root 44168 mag 7 23:51 /bin/ping*
[root@ubuntu ~]# setcap CAP_NET_RAW=ep /bin/ping
/bin/ping = cap_net_raw+ep
[root@ubuntu ~]#
Questa notatione va
bene anche per setcap

Funziona?
3 routeadd.
net
PING routeadd.
net (195.182.210.166) 56(84) bytes of data.
routeadd.

Da notare: le capability di ping in Fedora 20:
[root@fedora ~]# getcap /bin/ping
/bin/ping = cap_net_admin,cap_net_raw+ep
[root@fedora ~]#
CAP_NET_ADMIN contrassegna i pacchetti:
[alessandro@fedora ~]$ ping c1
m
123 routeadd.
net
PING routeadd.
net (195.182.210.166) 56(84) bytes of data.
Warning: Failed to set mark 123
routeadd.
[alessandro@fedora ~]$

AAllttrrii eesseemmppii 11--1111
Tutti conoscono gli Attributi Estesi POSIX, vero?
VVeerroo??
Se no, dovreste.
● Le LC sono utili, persino necessarie per usare gli
AEP.

AEP permettono di, ad es., impostare file:
a:
cui si possono solo aggiungere dati
i:
immutabili (né sovrascrivibili né cancell.)
S:
eseguono scritture sincrone
D:
directory che eseguono scritture sincrone
... (ce ne possono essere fino a 19)
Capire quale filesystem supporta quali AEP e
quali no è una vincita al lotto...

C'è però un inghippo:
● chattr non funziona per gli utenti ordinari:
[alessandro@fedora ~]$ chattr +i .bashrc
chattr: Operazione non permessa impostando i flag di
.bashrc

La soluzione classica UNIX è di farlo SUID root:
[root@fedora ~]# ll /usr/bin/chattr
rwxrxrx
1 root root 10528 giu 24 13:10 /usr/bin/chattr
[root@fedora ~]# chmod u+s /usr/bin/chattr
[root@fedora ~]# ll /usr/bin/chattr
rwsrxrx
1 root root 10528 giu 24 13:10 /usr/bin/chattr
[root@fedora ~]#
Funzionerebbe:
[alessandro@fedora ~]$ lsattr .bashrc
ie.
bashrc

Però...
[alessandro@fedora ~]$ lsattr ~games/.profile
e/
opt/games/.profile
[alessandro@fedora ~]$ chattr +i ~games/.profile
[alessandro@fedora ~]$ lsattr ~games/.profile
ie/
usr/games/.profile
Il che è normale per i privilegi di superutente.
Decisamente non vogliamo che questo accada.

Questa è la cosa giusta da fare:
[root@fedora ~]# chmod us
/bin/chattr
[root@fedora ~]# ll /bin/chattr
rwxrxrx
1 root root 10736 Aug 3 11:36 /bin/chattr
[root@fedora ~]# setcap CAP_LINUX_IMMUTABLE=ep /bin/chattr
[root@fedora ~]# getcap /bin/chattr
/bin/chattr = cap_linux_immutable+ep
[root@fedora ~]#

Che fa succedere le cose giuste:
e.
bashrc
ie.
bashrc
[alessandro@fedora ~]$ chattr +i ~games/.profile
chattr: Operazione non permessa impostando i flag di
/usr/games/.profile

"Mi spiace Dave, purtroppo non
posso farlo".

●DAC = Discretionary Access Control
● È il meccanismo classico Unix per decidere chi
può fare cosa
● Nel filesystem appare in forma dei diritti rwx
● Le LC possono incasinare anche loro! :-)

Suoniamo il cicalino! (In un xterm)
[alessandro@fedora ~]$ beep f
2000 l
100
Could not open /dev/tty0 or /dev/vc/0 for writing
open: No such file or directory
Il manuale dice:
Di default beep non è installato con il bit suid impostato, farlo
farebbe ridere. D'altra parte, renderlo suid root farebbe svanire
magicamente tutti i problemi con le chiamate ioctl, il che fa
piacere, e la sola regione di non volerlo fare è che ogni
programma suid è una potenziale falla di sicurezza. Per fortuna
beep è molto piccolo, ispezionarne il codice è piuttosto facile.

Usiamo le LC invece. L'errore era:
Could not open /dev/tty0 or /dev/vc/0 for writing
Ossia, è un problema di DAC.
[root@fedora ~]# setcap CAP_DAC_OVERRIDE=pe /bin/beep
[root@fedora ~]#
2000 l
100
ioctl: Operation not permitted
ioctl: Operation not permitted
CAP_SYS_TTY_CONFIG
Use vhangup(2); employ various privileged ioctl(2) operations
on virtual terminals.
Dal
manuale:

Tutte e due le capability insieme:
[root@fedora ~]# setcap
> CAP_DAC_OVERRIDE,CAP_SYS_TTY_CONFIG=pe /bin/beep
[root@fedora ~]#
2000 l
100

"Va bene Dave, credo di aver
capito come fare questo"

Estrazione/Decodifica informazioni
1-4
Quali LC sono attive adesso?
[root@ubuntu ~]# cp /bin/bash /tmp/
[root@ubuntu ~]# setcap CAP_KILL,CAP_DAC_OVERRIDE+epi /tmp/bash
[root@ubuntu ~]# getcap /tmp/bash
/tmp/bash = cap_dac_override,cap_kill+eip
[root@ubuntu ~]#
Ereditarietà impostata
[alessandro@ubuntu ~]$ /tmp/bash l
[alessandro@ubuntu ~]$ getpcaps $$
Capabilities for `15400': = cap_dac_override,cap_kill+ep
[alessandro@ubuntu ~]$ grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000000000000022
CapEff: 0000000000000022
CapBnd: 0000001fffffffff
Ereditarietà assente!

2-4
Decodifica della mappa di bit esadecimale LC:
CapInh: 0000000000000000
CapPrm: 0000000000000022
Rappresentata ancora
CapEff: 0000000000000022
come un set
[alessandro@ubuntu ~]$ capsh decode=
0000000000000000
0x0000000000000000=
0000000000000022
0x0000000000000022=cap_dac_override,cap_kill

3-4
0000001fffffffff = Capability Bounding Set
1 = cap permessa (mantenuta se presente)
0 = cap mascherata (o nessuna LC associata al bit)
I bit sono mappati uno-ad-uno alle LC
0000001fffffffff è una maschera a 64-bit
● È un campo a 64 bit dalla libcap versione 2.03
● Prima era a 32 bit

4-4
Il numero delle capability mappate è consistente
con il valore del conteggio da zero manteuto
in /proc/sys/kernel/cap_last_cap
Kernel 3.14.19:1fffffffff → 1+9*4=37
/proc/sys/kernel/cap_last_cap = 36
Kernel 3.16.3: 3fffffffff → 2+9*4=38
/proc/sys/kernel/cap_last_cap = 37

FFiillee ddii ccoonnffiigguurraazziioonnee 11--22
capability.conf1: utenti che ereditano le LC
[root@ubuntu ~]# cat /etc/security/capability.conf
cap_kill alessandro
none *
[root@ubuntu ~]#
Se assente tutti gli utenti avranno
ereditabili tutte le capability!
Le modifiche hanno effetto dopo un nuovo login:
Ubuntu 14.04.1 LTS ubuntu tty1
CAP_KILL adesso è ereditabile
ubuntu login: alessandro
Password:
Capabilities for `8586': = cap_kill+i

FFiillee ddii ccoonnffiigguurraazziioonnee 22--22
Il processo figlio della nuova shell eredita le LC:
Capabilities for `16332': = cap_kill+i
[alessandro@ubuntu ~]$ getcap /tmp/bash
/tmp/bash = cap_dac_override,cap_kill+eip
[alessandro@ubuntu ~]$ /tmp/bash l
Capabilities for `16849': = cap_kill+eip cap_dac_override+ep
Cap presente nel file
di configurazione
Cap assente nel file di
configurazione
1) Serve il pacchetto Ubuntu libpam-cap. Fedora ha quello libcap, ma
queste operazioni falliscono (PAM failure: System error)

Assegnazione ddeellllee ccaappaabbiilliittyy 11--1100
2.2.11 2.6.25 opzionale
Bounding-set di sistema Bounding-set per thread
2.6.33 integrato
● Prima del 2.6.25 Bounding Set era di sistema
● Dal 2.6.25 è per thread
● Dismesso da processo dotato di CAP_SETPCAP
con operazione prctl(2) PR_CAPBSET_DROP
● Ereditato in fork(2), mantenuto dopo execve(2)
● Opzionale dal 2.6.33, da allora integrato

N Nuovo P Precedente F Cap. impostata nel File
e capability
Effettiva p Capability Permessa i Capability ereditata
CBS Capability Bounding Set1
Le nuove capability erano calcolate così:
Np (Pi∪Fi)∩(Fp∪CBS)
Ne Fe∪Np
Ni Pi
1) Maschera delle capability permesse mantenute dopo execve(2). Nessun effetto su quelle ereditate.
Dal kernel 2.6.25 limita quelle ereditate che possono essere aggiunte a se stessi anche se permesse.

N Nuovo P Precedente F Cap. impostata nel File
e capability
Effettiva p Capability Permessa i Capability ereditata
CBS Capability Bounding Set1
Adesso sono calcolate così:
Np (Pi∪Fi)∩(Fp∪CBS)
Ne Fe ? Np : 02
Ni Pi
2) Non è più un AND perché il set Effettivo è un bit, non più un set (un bit per capability).

Cosa fa il Capability Bounding Set?
1) In un execve(2) toglie al thread le
capability permesse con un AND cap file.
2) Limita le cap ereditabili del thread che
possono essere aggiunte con un capset(2)
(kernel >= 2.6.25). Però:
a) la capability può essere ancora permessa;
b)la cap può essere ancora impostata se è
nel set ereditabile del file.

Potenziale rischio: cap accidentalmente permesse.
Si consideri la situazione:
1) processo genitore: CAP_X ered., non in CBS
2)CAP_X non sarà nel set permesso
a) ma rimane nel set ereditato dei figli
3) Il processo può eseguire figlio con CAP_X
nei set sia permesso che ereditato!
Togliere cap da CBS può dare un falso senso di
sicurezza! Da solo non basta!

Come per SUID, le LC degli script sono ignorati:
[alessandro@ubuntu ~]$ cat ~/bin/test_cap.sh
#!/bin/dash
getpcaps $$
grep ^Cap /proc/$$/status
[alessandro@ubuntu ~]$ getcap ~/bin/test_cap.sh
/home/alessandro/bin/test_cap.sh = cap_linux_immutable+ep
[alessandro@ubuntu ~]$ test_cap.sh
Capabilities for `9093': =
Ignorata
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Ignorata

Solo le LC degli eseguibili binari fanno testo:
[alessandro@ubuntu ~]$ cat ~/bin/test2_cap.sh
#!/tmp/dash
getpcaps $$
grep ^Cap /proc/$$/status
[alessandro@ubuntu ~]$ getcap ~/bin/test2_cap.sh /tmp/dash
/tmp/dash = cap_linux_immutable+ep
[alessandro@ubuntu ~]$ test2_cap.sh
Capabilities for `9218': = cap_linux_immutable+ep
CapInh: 0000000000000000
CapPrm: 0000000000000200
CapEff: 0000000000000200
Presente Presente

capsh può ridurre le CBS della shell:
[alessandro@ubuntu ~]$ getcap $(which capsh)
/sbin/capsh = cap_setpcap+p
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
[alessandro@ubuntu ~]$ capsh drop=
cap_net_raw [
alessandro@ubuntu ~]$ grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffdfff

Riduzione CBS con capsh. Situazione iniziale:
[alessandro@ubuntu ~]$ getcap $(which capsh ping)
/sbin/capsh = cap_setpcap+p
/bin/ping = cap_net_raw+p
Capabilities for `7842': =
[alessandro@ubuntu ~]$ ping qc1
routeadd.
net
PING routeadd.
net (195.182.210.166) 56(84) bytes of data.
routeadd.

Esecuzione shell con CBS ridotte via capsh:
[alessandro@ubuntu ~]$ capsh drop=
cap_net_raw [
alessandro@ubuntu ~]$ grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
!
CapEff: 0000000000000000
CapBnd: 0000001fffffdfff
2000
0x0000000000002000=cap_net_raw
[alessandro@ubuntu ~]$ ping qc1
routeadd.
net
ping: icmp open socket: Operation not permitted

SSttaattoo ddii aallccuunnee ddiissttrriibbuuzziioonnii 11--77
Lo scopo è di sostituire ovunque possibile agli
eseguibili i bit SUID/SGID con le capability:
● Fedora: ultimo aggiornamento: 2011-04-05,
completato: 100% (molti, non tutti, i SUID
tolti)
● Ubuntu: lavori in corso (ultimo aggiornamento:
2011-09-27)
Non è ancora possibile sostituire tutti i SUID con
le Linux Capabilities

Fedora 20 (Heisenbug): un paio di dozzine di file
suid (in un'installazione LXDE non-standard)
# find / xdev
type
f perm
/111 perm
/4000 user
root | wc l
23
#
/usr/sbin/mount.nfs /usr/bin/mount /usr/bin/chsh /usr/bin/write
/usr/bin/fusermount /usr/bin/umount /usr/bin/chage /usr/bin/passwd
/usr/bin/newgrp /usr/bin/locate /usr/bin/su /usr/bin/sudo
/usr/bin/gpasswd /usr/bin/cgexec /usr/bin/chfn /usr/bin/Xorg
/usr/bin/sshagent
/usr/bin/crontab /usr/bin/at /usr/bin/ksu
/usr/sbin/postqueue /usr/sbin/postdrop /usr/sbin/ssmtp /usr/bin/pkexec

Ubuntu 14.04.1 (Trusty Tahr): alcune di più
(ancora in un'installazione XFCE non-standard)
# find / /usr xdev
type
f perm
/111 perm
/4000 user
root | wc l
29
#
Erano 34 in 13.10 (Saucy Salamander)

Stato ddii aallccuunnee ddiissttrriibbuuzziioonnii 44--77
Vediamo un caso in cui le LC non funzionano:
[alessandro@fedora ~]$ ll /usr/bin/at
rwsrxrx
1 root root 53208 5 dic 12.34 /usr/bin/at
[alessandro@fedora ~]$ getcap /usr/bin/at
Togliamo il bit SUID e qualsiasi capability:
[root@fedora ~]# chmod us
/usr/bin/at
[root@fedora ~]# setcap r
/usr/bin/at
[root@fedora ~]#
[alessandro@fedora ~]$ at f
~/bin/at.sh now+5min
cannot set egid: Operation not permitted

Cerchiamo di farlo felice:
[root@fedora ~]# setcap CAP_SETGID+ep /usr/bin/at
[root@fedora ~]#
Nessuna fortuna:
cannot set euid: Operation not permitted
[root@fedora ~]# setcap CAP_SETUID,CAP_SETGID+ep /usr/bin/at
[root@fedora ~]#
PAM failure: System error
[alessandro@fedora ~]$ :(

Nel file di log compare:
[alessandro@fedora ~]$ tail 1
/var/log/secure
Feb 23 10:08:43 fedora at: PAM audit_log_acct_message()
failed: Operation not permitted
Nulla da fare, per ora.

Ubuntu ha seguito una strada diversa:
● usa la stessa implementazione di at/atd (di
Thomas Koenig, ig25@rz.uni-karlsruhe.de)
● il demone gira come utente daemon
● l'eseguibile del client è SUID e SGUI
daemon:daemon, il che gli permette di:
 scrivere in /var/spool/cron/atjobs/.SEQ
 mandare segnali ad atd
Vecchia scuola, semplice, efficace, sicuro.

PPrroobblleemmii?? 11--22
«Perché così poche persone conoscono e usano
le capability? Credo che la documentazione
scarsa sia la ragione principale. Per esempio,
la Fedora 10 non ha le pagine man di
getpcaps, capsh e pam_cap, e la Guida
alla Sicurezza di Fedora neppure nomina le
capability»
(Finnbarr P. Murphy, 28 maggio 2009 )
Tutto vero ancora oggi!

PPrroobblleemmii?? 22--22
●Documentazione online distrib. ferma da anni
● La Guida alla Sicurezza di Fedora nelle stesse
condizioni alla vers. 19.1, e manca nella 20
➢Ma almeno le pagine man ci sono
➢ Nel suo futuro solo SELinux?
● Il comportamento delle LC è cambiato
➢ Gli stessi comandi, capability e set hanno
effetti diversi rispetto a 2.6.24 senza errori
● libcap-ng rende la programmazione più facile

RRiinnggrraazziiaammeennttii 11--11
● Quelli del progetto Linux man-pages (
https://www.kernel.org/doc/man-pages/)
● Finnbarr P. Murphy (post di blog e riferimenti,
utile anche se superato)
● E gli sviluppatori del kernel, naturalmente!
 Andrew G. Morgan <morgan@kernel.org>
 Alexander Kjeldaas <astor@guardian.no> con
contributi di Aleph1, Roland Buresund e Andrew
Main.

Linux Capabilities - ita - v2.1.5 - compatta

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Linux Capabilities - ita - v2.1.5 - compatta

Similar a Linux Capabilities - ita - v2.1.5 - compatta (20)

Linux Capabilities - ita - v2.1.5 - compatta