capabilities(7)

Från Wiki.linux.se
Hoppa till navigering Hoppa till sök

Capabilities(7) Manual för Diverse Information Capabilities(7)

NAMN

capabilities - översikt över Linux-kapaciteter

BESKRIVNING

För att utföra behörighetskontroller skiljer traditionella UNIX-implementationer mellan två kategorier av processer: privilegierade processer (vars effektiva användar-ID är 0, kallad superuser eller root) och oprivilegierade processer (vars effektiva UID är icke-noll). Privilegierade processer kringgår alla kärnans behörighetskontroller, medan oprivilegierade processer är föremål för fullständig behörighetskontroll baserad på processens referenser (vanligtvis: effektiv UID, effektiv GID och kompletterande grupplista).

Från och med Linux 2.2 delar Linux upp de privilegier som traditionellt associeras med superuser i distinkta enheter, kända som kapaciteter, som kan aktiveras och avaktiveras oberoende. Kapaciteter är en attribut per tråd.

Kapacitetslista

Följande lista visar de kapaciteter som implementeras på Linux och de operationer eller beteenden som varje kapacitet tillåter:

CAP_AUDIT_CONTROL (sedan Linux 2.6.11)

Aktivera och inaktivera kärnrevision; ändra revisionsfilterregler; hämta revisionsstatus och filtreringsregler.

CAP_AUDIT_READ (sedan Linux 3.16)

Tillåter läsning av revisionsloggen via en multicast netlink-socket.

CAP_AUDIT_WRITE (sedan Linux 2.6.11)

Skriv poster till kärnans revisionslogg.

CAP_BLOCK_SUSPEND (sedan Linux 3.5)

Använd funktioner som kan blockera systemets suspendering (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).

CAP_BPF (sedan Linux 5.8)

Använd privilegierade BPF-operationer; se bpf(2) och bpf-helpers(7).

Denna kapacitet lades till i Linux 5.8 för att separera BPF-funktionalitet från den överbelastade CAP_SYS_ADMIN-kapaciteten.

CAP_CHECKPOINT_RESTORE (sedan Linux 5.9)

  • Uppdatera /proc/sys/kernel/ns_last_pid (se pid_namespaces(7));
  • använda set_tid-funktionen i clone3(2);
  • läsa innehållet i de symboliska länkarna i /proc/pid/map_files för andra processer.

Denna kapacitet lades till i Linux 5.9 för att separera checkpoint/restore-funktionalitet från den överbelastade CAP_SYS_ADMIN-kapaciteten.

CAP_CHOWN

Göra godtyckliga ändringar av filens UID och GID (se chown(2)).

CAP_DAC_OVERRIDE

Kringgå filens läs-, skriv- och exekveringsbehörighetskontroller. (DAC är en förkortning för "discretionary access control".)

CAP_DAC_READ_SEARCH

  • Kringgå filens läsbehörighetskontroller och katalogens läs- och exekveringsbehörighetskontroller;
  • anropa open_by_handle_at(2);
  • använda flaggan AT_EMPTY_PATH med linkat(2) för att skapa en länk till en fil som refereras av en filbeskrivare.

CAP_FOWNER

  • Kringgå behörighetskontroller på operationer som normalt kräver att processens filsystem-UID matchar filens UID (t.ex. chmod(2), utime(2)), exklusive de operationer som täcks av CAP_DAC_OVERRIDE och CAP_DAC_READ_SEARCH;
  • ställa in inode-flaggor (se FS_IOC_SETFLAGS(2const)) på godtyckliga filer;
  • ställa in Access Control Lists (ACL) på godtyckliga filer;
  • ignorera katalogens sticky bit vid filradering;
  • modifiera användarens utökade attribut på en sticky-katalog ägd av vilken användare som helst;
  • specificera O_NOATIME för godtyckliga filer i open(2) och fcntl(2).

CAP_FSETID

  • Rensa inte set-user-ID och set-group-ID-lägesbitar när en fil modifieras;
  • ställa in set-group-ID-biten för en fil vars GID inte matchar filsystemet eller någon av processens kompletterande GID.

CAP_IPC_LOCK

CAP_IPC_OWNER

Kringgå behörighetskontroller för operationer på System V IPC-objekt.

CAP_KILL

Kringgå behörighetskontroller för att skicka signaler (se kill(2)). Detta inkluderar användning av ioctl(2) KDSIGACCEPT-operationen.

CAP_LEASE (sedan Linux 2.4)

Etablera leases på godtyckliga filer (se fcntl(2)).

CAP_LINUX_IMMUTABLE

Ställa in FS_APPEND_FL och FS_IMMUTABLE_FL inode-flaggor (se FS_IOC_SETFLAGS(2const)).

CAP_MAC_ADMIN (sedan Linux 2.6.25)

Tillåta MAC-konfiguration eller tillståndsändringar. Implementerad för Smack Linux Security Module (LSM).

CAP_MAC_OVERRIDE (sedan Linux 2.6.25)

Överstyr Mandatory Access Control (MAC). Implementerad för Smack LSM.

CAP_MKNOD (sedan Linux 2.4)

Skapa specialfiler med hjälp av mknod(2).

CAP_NET_ADMIN

Utföra olika nätverksrelaterade operationer:
  • gränssnittskonfiguration;
  • administration av IP-brandvägg, maskering och redovisning;
  • modifiera routningstabeller;
  • binda till vilken adress som helst för transparent proxying;
  • ställa in type-of-service (TOS);
  • rensa drivrutinsstatistik;
  • ställa in promiskuöst läge;
  • aktivera multicast;
  • använda setsockopt(2) för att ställa in följande socket-alternativ: SO_DEBUG, SO_MARK, SO_PRIORITY (för en prioritet utanför intervallet 0 till 6), SO_RCVBUFFORCE och SO_SNDBUFFORCE.

CAP_NET_BIND_SERVICE

Binda en socket till privilegierade Internet-domänportar (portnummer mindre än 1024).

CAP_NET_BROADCAST

(Används inte) Skicka socket-sändningar och lyssna på multicast.

CAP_NET_RAW

  • Använda RAW och PACKET-sockets;
  • binda till vilken adress som helst för transparent proxying.

CAP_PERFMON (sedan Linux 5.8)

Använda olika prestandaövervakningsmekanismer, inklusive:

Denna kapacitet lades till i Linux 5.8 för att separera prestandaövervakningsfunktionalitet från den överbelastade CAP_SYS_ADMIN-kapaciteten. Se även kärnkällfilen Documentation/admin-guide/perf-security.rst.

CAP_SETGID

  • Göra godtyckliga manipulationer av processens GID och kompletterande GID-lista;
  • förfalska GID när man passerar socket-referenser via UNIX-domänsockets;
  • skriva en grupp-ID-mappning i ett användarnamnsutrymme (se user_namespaces(7)).

CAP_SETFCAP (sedan Linux 2.6.24)

Ställa in godtyckliga kapaciteter på en fil.

Sedan Linux 5.12 krävs denna kapacitet också för att mappa användar-ID 0 i ett nytt användarnamnsutrymme; se user_namespaces(7) för detaljer.

CAP_SETPCAP

Om filkapaciteter stöds (dvs. sedan Linux 2.6.24): lägg till någon kapacitet från den anropande trådens begränsningsuppsättning till dess ärftliga uppsättning; ta bort kapaciteter från begränsningsuppsättningen (via prctl(2) PR_CAPBSET_DROP); gör ändringar i securebits-flaggorna.

Om filkapaciteter inte stöds (dvs. före Linux 2.6.24): ge eller ta bort någon kapacitet i anroparens tillåtna kapacitetsuppsättning till eller från någon annan process. (Denna egenskap hos CAP_SETPCAP är inte tillgänglig när kärnan är konfigurerad för att stödja filkapaciteter, eftersom CAP_SETPCAP har helt olika semantik för sådana kärnor.)

CAP_SETUID

CAP_SYS_ADMIN Observera: denna kapacitet är överbelastad; se Anteckningar till kärnutvecklare nedan.

CAP_SYS_BOOT

Använda reboot(2) och kexec_load(2).

CAP_SYS_CHROOT

CAP_SYS_MODULE

  • Ladda och avlasta kärnmoduler (se init_module(2) och delete_module(2));
  • före Linux 2.6.25: ta bort kapaciteter från den systemomfattande kapacitetsbegränsningsuppsättningen.

CAP_SYS_NICE

CAP_SYS_PACCT

Använda acct(2).

CAP_SYS_PTRACE

CAP_SYS_RAWIO

  • Utföra I/O-portoperationer (iopl(2) och ioperm(2));
  • komma åt /proc/kcore;
  • använda FIBMAP ioctl(2)-operationen;
  • öppna enheter för att komma åt x86-modellspecifika register (MSR, se msr(4));
  • uppdatera /proc/sys/vm/mmap_min_addr;
  • skapa minnesmappningar vid adresser under värdet som anges av /proc/sys/vm/mmap_min_addr;
  • mappa filer i /proc/bus/pci;
  • öppna /dev/mem och /dev/kmem;
  • utföra olika SCSI-enhetskommandon;
  • utföra vissa operationer på hpsa(4) och cciss(4)-enheter;
  • utföra en rad enhetsspecifika operationer på andra enheter.

CAP_SYS_RESOURCE

  • Använda reserverat utrymme på ext2-filsystem;
  • göra ioctl(2)-anrop som kontrollerar ext3-journalföring;
  • överstiga diskquota-gränser;
  • öka resursgränser (se setrlimit(2));
  • överstiga RLIMIT_NPROC-resursgränsen;
  • överstiga maximalt antal konsoler vid konsoltilldelning;
  • överstiga maximalt antal keymaps;
  • tillåta mer än 64hz-interrupt från realtidsklockan;
  • höja msg_qbytes-gränsen för en System V-meddelandekö över gränsen i /proc/sys/kernel/msgmnb (se msgop(2) och msgctl(2));
  • tillåta att RLIMIT_NOFILE-resursgränsen för antalet "in-flight" filbeskrivare kringgås när man passerar filbeskrivare till en annan process via en UNIX-domänsocket (se unix(7));
  • kringgå /proc/sys/fs/pipe-size-max-gränsen när man ställer in kapaciteten för en pipe med hjälp av F_SETPIPE_SZ fcntl(2)-kommandot;
  • använda F_SETPIPE_SZ för att öka kapaciteten hos en pipe över gränsen som specificeras av /proc/sys/fs/pipe-max-size;
  • kringgå /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max och /proc/sys/fs/mqueue/msgsize_max-gränser när man skapar POSIX-meddelandeköer (se mq_overview(7));
  • använda prctl(2) PR_SET_MM-operationen;
  • ställa in /proc/pid/oom_score_adj till ett värde lägre än det värde som senast ställts in av en process med CAP_SYS_RESOURCE.

CAP_SYS_TIME

Ställa in systemklockan (settimeofday(2), stime(2), adjtimex(2)); ställa in realtidsklockan.

CAP_SYS_TTY_CONFIG

Använda vhangup(2); använda olika privilegierade ioctl(2)-operationer på virtuella terminaler.

CAP_SYSLOG (sedan Linux 2.6.37)

  • Utföra privilegierade syslog(2)-operationer. Se syslog(2) för information om vilka operationer som kräver privilegier.
  • Visa kärnadresser som exponeras via /proc och andra gränssnitt när /proc/sys/kernel/kptr_restrict har värdet 1. (Se diskussionen om kptr_restrict i proc(5).)

CAP_WAKE_ALARM (sedan Linux 3.0)

Utlösa något som väcker systemet (ställa in CLOCK_REALTIME_ALARM och CLOCK_BOOTTIME_ALARM-timers).

Tidigare och nuvarande implementering

En fullständig implementering av kapaciteter kräver att:

  • För alla privilegierade operationer måste kärnan kontrollera om tråden har den erforderliga kapaciteten i sin effektiva uppsättning.
  • Kärnan måste tillhandahålla systemanrop som tillåter att en tråds kapacitetsuppsättningar ändras och hämtas.
  • Filsystemet måste stödja att koppla kapaciteter till en körbar fil, så att en process får dessa kapaciteter när filen exekveras.

Före Linux 2.6.24 uppfylls endast de två första av dessa krav; sedan Linux 2.6.24 uppfylls alla tre kraven.

Anteckningar till kärnutvecklare

När du lägger till en ny kärnfunktion som bör styras av en kapacitet, överväg följande punkter.

  • Målet med kapaciteter är att dela upp superanvändarens kraft i delar, så att om ett program som har en eller flera kapaciteter äventyras, skulle dess förmåga att skada systemet vara mindre än samma program som körs med root-privilegier.
  • Du har valet att antingen skapa en ny kapacitet för din nya funktion eller associera funktionen med en av de befintliga kapaciteterna. För att hålla mängden kapaciteter hanterbar är det senare alternativet att föredra, om det inte finns tvingande skäl att välja det första alternativet. (Det finns också en teknisk begränsning: storleken på kapacitetsuppsättningar är för närvarande begränsad till 64 bitar.)
  • För att bestämma vilken befintlig kapacitet som bäst kan associeras med din nya funktion, granska listan över kapaciteter ovan för att hitta en "silo" där din nya funktion bäst passar in. En metod är att avgöra om det finns andra funktioner som kräver kapaciteter som alltid kommer att användas tillsammans med den nya funktionen. Om den nya funktionen är värdelös utan dessa andra funktioner bör du använda samma kapacitet som de andra funktionerna.
  • Välj inte CAP_SYS_ADMIN om du kan undvika det! En stor andel av befintliga kapacitetskontroller är associerade med denna kapacitet (se den partiella listan ovan). Det kan rimligen kallas "den nya root", eftersom det å ena sidan ger en rad krafter, och å andra sidan innebär dess breda omfattning att detta är kapaciteten som krävs av många privilegierade program. Gör inte problemet värre. De enda nya funktioner som bör associeras med CAP_SYS_ADMIN är de som nära matchar befintliga användningar i den silon.
  • Om du har bestämt att det verkligen är nödvändigt att skapa en ny kapacitet för din funktion, gör den inte eller namnge den som en "engångs"-kapacitet. Således var tillägget av den mycket specifika CAP_SYS_PACCT förmodligen ett misstag. Försök istället att identifiera och namnge din nya kapacitet som en bredare silo där andra relaterade framtida användningsfall kan passa.

Trådkapacitetsuppsättningar

Varje tråd har följande kapacitetsuppsättningar som innehåller noll eller fler av ovanstående kapaciteter:

Tillåten

Detta är en begränsande överuppsättning för de effektiva kapaciteter som tråden kan anta. Det är också en begränsande överuppsättning för de kapaciteter som kan läggas till i den ärftliga uppsättningen av en tråd som inte har CAP_SETPCAP-kapaciteten i sin effektiva uppsättning.

Om en tråd släpper en kapacitet från sin tillåtna uppsättning kan den aldrig återfå den kapaciteten (om den inte execve(2):ar antingen ett set-user-ID-root-program eller ett program vars associerade filkapaciteter ger den kapaciteten).

Ärftlig

Detta är en uppsättning kapaciteter som bevaras över en execve(2). Ärftliga kapaciteter förblir ärftliga när man exekverar något program, och ärftliga kapaciteter läggs till i den tillåtna uppsättningen när man exekverar ett program som har motsvarande bitar inställda i filens ärftliga uppsättning.

Eftersom ärftliga kapaciteter inte generellt bevaras över execve(2) när man kör som en icke-root-användare, bör applikationer som vill köra hjälpprogram med förhöjda kapaciteter överväga att använda omgivande kapaciteter, beskrivna nedan.

Effektiv

Detta är uppsättningen av kapaciteter som används av kärnan för att utföra behörighetskontroller för tråden.

Begränsande (per tråd sedan Linux 2.6.25)

Kapacitetsbegränsningsuppsättningen är en mekanism som kan användas för att begränsa de kapaciteter som erhålls under en execve(2).

Sedan Linux 2.6.25 är detta en kapacitetsuppsättning per tråd. I äldre kärnor var kapacitetsbegränsningsuppsättningen en systemomfattande attribut som delades av alla trådar på systemet.

För mer detaljer, se Kapacitetsbegränsningsuppsättningen nedan.

Omgivande (sedan Linux 4.3)

Detta är en uppsättning kapaciteter som bevaras över en execve(2) av ett program som inte är privilegierat. Den omgivande kapacitetsuppsättningen följer invariantet att ingen kapacitet någonsin kan vara omgivande om den inte både är tillåten och ärftlig.

Den omgivande kapacitetsuppsättningen kan direkt modifieras med hjälp av prctl(2). Omgivande kapaciteter sänks automatiskt om antingen motsvarande tillåtna eller ärftliga kapaciteter sänks.

Att exekvera ett program som ändrar UID eller GID på grund av set-user-ID eller set-group-ID-bitarna eller att exekvera ett program som har några filkapaciteter inställda kommer att rensa den omgivande uppsättningen. Omgivande kapaciteter läggs till i den tillåtna uppsättningen och tilldelas den effektiva uppsättningen när execve(2) anropas. Om omgivande kapaciteter orsakar att en process tillåtna och effektiva kapaciteter ökar under en execve(2), utlöser detta inte det säkra exekveringsläget som beskrivs i ld.so(8).

En barnprocess som skapas via fork(2) ärver kopior av sin förälders kapacitetsuppsättningar. För detaljer om hur execve(2) påverkar kapaciteter, se Transformation av kapaciteter under execve() nedan.

Med hjälp av capset(2) kan en tråd manipulera sina egna kapacitetsuppsättningar; se Programmatisk justering av kapacitetsuppsättningar nedan.

Sedan Linux 3.2 exponerar filen /proc/sys/kernel/cap_last_cap det numeriska värdet av den högsta kapaciteten som stöds av den körande kärnan; detta kan användas för att bestämma den högsta biten som kan ställas in i en kapacitetsuppsättning.

Filkapaciteter

Sedan Linux 2.6.24 stöder kärnan att associera kapacitetsuppsättningar med en körbar fil med hjälp av setcap(8). Filens kapacitetsuppsättningar lagras i ett utökat attribut (se setxattr(2) och xattr(7)) med namnet security.capability. Att skriva till detta utökade attribut kräver CAP_SETFCAP-kapaciteten. Filens kapacitetsuppsättningar, tillsammans med trådens kapacitetsuppsättningar, bestämmer kapaciteterna för en tråd efter en execve(2).

De tre filkapacitetsuppsättningarna är:

Tillåten (tidigare känd som tvingad):

Dessa kapaciteter tillåts automatiskt till tråden, oavsett trådens ärftliga kapaciteter.

Ärftlig (tidigare känd som tillåten):

Denna uppsättning OCH:as med trådens ärftliga uppsättning för att bestämma vilka ärftliga kapaciteter som aktiveras i trådens tillåtna uppsättning efter execve(2).

Effektiv:

Detta är inte en uppsättning, utan snarare bara en enda bit. Om denna bit är inställd, höjs alla nya tillåtna kapaciteter för tråden också i den effektiva uppsättningen under en execve(2). Om denna bit inte är inställd, finns inga nya tillåtna kapaciteter i den nya effektiva uppsättningen efter en execve(2).

Att aktivera den effektiva filkapacitetsbiten innebär att varje fil tillåten eller ärftlig kapacitet som orsakar att en tråd förvärvar motsvarande tillåtna kapacitet under en execve(2) också kommer att förvärva den kapaciteten i sin effektiva uppsättning. Därför, när man tilldelar kapaciteter till en fil (setcap(8), cap_set_file(3), cap_set_fd(3)), om vi specificerar att den effektiva flaggan är aktiverad för någon kapacitet, måste den effektiva flaggan också specificeras som aktiverad för alla andra kapaciteter för vilka motsvarande tillåtna eller ärftliga flagga är aktiverad.

Filkapacitetsutökat attribut versionering

För att möjliggöra utbyggbarhet stöder kärnan ett schema för att koda ett versionsnummer inuti det utökade attributet security.capability som används för att implementera filkapaciteter. Dessa versionsnummer är interna för implementeringen och inte direkt synliga för användarutrymmesapplikationer. Hittills stöds följande versioner:

VFS_CAP_REVISION_1

Detta var den ursprungliga filkapacitetsimplementeringen, som stödde 32-bitars maskor för filkapaciteter.

VFS_CAP_REVISION_2 (sedan Linux 2.6.25)

Denna version tillåter filkapacitetsmaskor som är 64 bitar stora och var nödvändig eftersom antalet stödda kapaciteter växte bortom 32. Kärnan fortsätter transparent att stödja exekvering av filer som har 32-bitars version 1 kapacitetsmaskor, men när man lägger till kapaciteter till filer som inte tidigare hade kapaciteter, eller modifierar kapaciteterna hos befintliga filer, använder den automatiskt versions 2-schemat (eller möjligen versions 3-schemat, som beskrivs nedan).

VFS_CAP_REVISION_3 (sedan Linux 4.14)

Version 3 filkapaciteter tillhandahålls för att stödja namnutrymmesfilkapaciteter (beskrivna nedan).

Liksom version 2 filkapaciteter är version 3 kapacitetsmaskor 64 bitar stora. Men dessutom kodas rotanvändar-ID:t för namnutrymmet i det utökade attributet security.capability. (Ett namnutrymmes rotanvändar-ID är det värde som användar-ID 0 inuti det namnutrymmet mappas till i det initiala användarnamnsutrymmet.)

Version 3 filkapaciteter är utformade för att samexistera med version 2 kapaciteter; det vill säga, på ett modernt Linux-system kan det finnas några filer med version 2 kapaciteter medan andra har version 3 kapaciteter.

Före Linux 4.14 kunde endast en typ av filkapacitetsutökat attribut kopplas till en fil: ett VFS_CAP_REVISION_2-attribut. Sedan Linux 4.14 beror versionen av det utökade attributet security.capability som kopplas till en fil på de omständigheter under vilka attributet skapades.

Från och med Linux 4.14 skapas ett utökat attribut security.capability automatiskt som (eller konverteras till) ett version 3 (VFS_CAP_REVISION_3) attribut om båda följande är sanna:

  • Tråden som skriver attributet befinner sig i ett icke-initialt användarnamnsutrymme. (Mer exakt: tråden befinner sig i ett användarnamnsutrymme annat än det från vilket det underliggande filsystemet monterades.)
  • Tråden har CAP_SETFCAP-kapaciteten över filens inode, vilket betyder att (a) tråden har CAP_SETFCAP-kapaciteten i sitt eget användarnamnsutrymme; och (b) filens inode UID och GID har mappningar i skrivarens användarnamnsutrymme.

När ett VFS_CAP_REVISION_3 security.capability-utökat attribut skapas, sparas rotanvändar-ID:t för det skapande trådens användarnamnsutrymme i det utökade attributet.

Däremot resulterar skapande eller modifiering av ett security.capability-utökat attribut från en privilegierad (CAP_SETFCAP) tråd som befinner sig i det namnutrymme där det underliggande filsystemet monterades (detta betyder normalt det initiala användarnamnsutrymmet) automatiskt i skapandet av ett version 2 (VFS_CAP_REVISION_2) attribut.

Observera att skapandet av ett version 3 security.capability-utökat attribut är automatiskt. Det vill säga, när en användarutrymmesapplikation skriver (setxattr(2)) ett security.capability-attribut i version 2-format, kommer kärnan automatiskt att skapa ett version 3-attribut om attributet skapas under de omständigheter som beskrivs ovan. Motsvarande, när ett version 3 security.capability-attribut hämtas (getxattr(2)) av en process som befinner sig inuti ett användarnamnsutrymme som skapades av rotanvändar-ID:t (eller en ättling till det användarnamnsutrymmet), förenklas det returnerade attributet (automatiskt) för att visas som ett version 2-attribut (dvs. det returnerade värdet är storleken på ett version 2-attribut och inkluderar inte rotanvändar-ID:t). Dessa automatiska översättningar innebär att inga ändringar krävs för användarutrymmesverktyg (t.ex. setcap(1) och getcap(1)) för att dessa verktyg ska kunna användas för att skapa och hämta version 3 security.capability-attribut.

Observera att en fil kan ha antingen ett version 2 eller ett version 3 security.capability-utökat attribut associerat med sig, men inte båda: skapande eller modifiering av det utökade attributet security.capability kommer automatiskt att ändra versionen enligt de omständigheter under vilka det utökade attributet skapas eller modifieras.

Transformation av kapaciteter under execve()

Under en execve(2) beräknar kärnan processens nya kapaciteter med följande algoritm:

P'(ambient) = (filen är privilegierad) ? 0 : P(ambient)

P'(permitted) = (P(inheritable) & F(inheritable)) | 

                 (F(permitted) & P(bounding)) | P'(ambient)

P'(effective) = F(effective) ? P'(permitted) : P'(ambient)

P'(inheritable) = P(inheritable) [dvs. oförändrad]

P'(bounding) = P(bounding) [dvs. oförändrad]

där:

P() betecknar värdet av en tråds kapacitetsuppsättning före execve(2)

P'() betecknar värdet av en tråds kapacitetsuppsättning efter execve(2)

F() betecknar en filkapacitetsuppsättning

Notera följande detaljer relaterade till ovanstående kapacitetstransformationsregler:

  • Den omgivande kapacitetsuppsättningen finns endast sedan Linux 4.3. När man bestämmer transformationen av den omgivande uppsättningen under execve(2) är en privilegierad fil en som har kapaciteter eller har set-user-ID eller set-group-ID-biten inställd.
  • Före Linux 2.6.25 var kapacitetsbegränsningsuppsättningen en systemomfattande attribut som delades av alla trådar. Det systemomfattande värdet användes för att beräkna den nya tillåtna uppsättningen under execve(2) på samma sätt som visas ovan för P(bounding).

Notera: under de kapacitetstransformationer som beskrivs ovan kan filkapaciteter ignoreras (behandlas som tomma) av samma skäl som set-user-ID och set-group-ID-bitarna ignoreras; se execve(2). Filkapaciteter ignoreras på liknande sätt om kärnan startades med no_file_caps-alternativet.

Notera: enligt ovanstående regler, om en process med icke-noll användar-ID:n utför en execve(2), kommer alla kapaciteter som finns i dess tillåtna och effektiva uppsättningar att rensas. För behandlingen av kapaciteter när en process med användar-ID 0 utför en execve(2), se Kapaciteter och exekvering av program av root nedan.

Säkerhetskontroll för kapacitetsokunniga binärer

En kapacitetsokunnig binär är en applikation som har markerats för att ha filkapaciteter, men som inte har konverterats för att använda libcap(3)-API:et för att manipulera dess kapaciteter. (Med andra ord är detta ett traditionellt set-user-ID-root-program som har växlats för att använda filkapaciteter, men vars kod inte har modifierats för att förstå kapaciteter.) För sådana applikationer ställs den effektiva kapacitetsbiten in på filen, så att filens tillåtna kapaciteter automatiskt aktiveras i processens effektiva uppsättning när filen exekveras. Kärnan känner igen en fil som har den effektiva kapacitetsbiten inställd som kapacitetsokunnig för syftet med kontrollen som beskrivs här.

När man exekverar en kapacitetsokunnig binär kontrollerar kärnan om processen erhöll alla tillåtna kapaciteter som specificerades i filens tillåtna uppsättning, efter att de kapacitetstransformationer som beskrivs ovan har utförts. (Den typiska anledningen till att detta kanske inte sker är att kapacitetsbegränsningsuppsättningen maskerade bort några av kapaciteterna i filens tillåtna uppsättning.) Om processen inte erhöll hela uppsättningen av filens tillåtna kapaciteter, misslyckas execve(2) med felet EPERM. Detta förhindrar möjliga säkerhetsrisker som kan uppstå när en kapacitetsokunnig applikation exekveras med mindre privilegier än den behöver. Notera att, per definition, applikationen själv inte kunde känna igen detta problem, eftersom den inte använder libcap(3)-API:et.

Kapaciteter och exekvering av program av root

För att spegla traditionell UNIX-semantik utför kärnan särskild behandling av filkapaciteter när en process med UID 0 (root) exekverar ett program och när ett set-user-ID-root-program exekveras.

Efter att ha utfört eventuella ändringar av processens effektiva ID som utlöstes av set-user-ID-lägesbiten i binären – t.ex. växla det effektiva användar-ID:t till 0 (root) eftersom ett set-user-ID-root-program exekverades – beräknar kärnan filkapacitetsuppsättningarna enligt följande:

(1) Om processens verkliga eller effektiva användar-ID är 0 (root) ignoreras filens ärftliga och tillåtna uppsättningar; istället anses de vara alla ettor (dvs. alla kapaciteter aktiverade). (Det finns ett undantag från detta beteende, beskrivet i Set-user-ID-root-program som har filkapaciteter nedan.)

(2) Om processens effektiva användar-ID är 0 (root) eller om filens effektiva bit faktiskt är aktiverad, definieras filens effektiva bit att vara ett (aktiverad).

Dessa tänkta värden för filens kapacitetsuppsättningar används sedan som beskrivs ovan för att beräkna transformationen av processens kapaciteter under execve(2).

Således, när en process med icke-noll UID:er execve(2):ar ett set-user-ID-root-program som inte har kapaciteter kopplade, eller när en process vars verkliga och effektiva UID:er är noll execve(2):ar ett program, förenklas beräkningen av processens nya tillåtna kapaciteter till:

P'(permitted) = P(inheritable) | P(bounding)

P'(effective) = P'(permitted)

Följaktligen får processen alla kapaciteter i sina tillåtna och effektiva kapacitetsuppsättningar, förutom de som maskeras bort av kapacitetsbegränsningsuppsättningen. (I beräkningen av P'(permitted) kan P'(ambient)-termen förenklas bort eftersom den per definition är en äkta delmängd av P(inheritable).)

De särskilda behandlingarna av användar-ID 0 (root) som beskrivs i denna undersektion kan inaktiveras med hjälp av securebits-mekanismen som beskrivs nedan.

Set-user-ID-root-program som har filkapaciteter

Det finns ett undantag från beteendet som beskrivs i Kapaciteter och exekvering av program av root ovan. Om (a) binären som exekveras har kapaciteter kopplade och (b) processens verkliga användar-ID inte är 0 (root) och (c) processens effektiva användar-ID är 0 (root), då respekteras filkapacitetsbitarna (dvs. de anses inte vara alla ettor). Det vanliga sättet på vilket denna situation kan uppstå är när man exekverar ett set-UID-root-program som också har filkapaciteter. När ett sådant program exekveras får processen bara de kapaciteter som beviljas av programmet (dvs. inte alla kapaciteter, som skulle inträffa när man exekverar ett set-user-ID-root-program som inte har några associerade filkapaciteter).

Observera att man kan tilldela tomma kapacitetsuppsättningar till ett programfil, och därmed är det möjligt att skapa ett set-user-ID-root-program som ändrar processens effektiva och sparade set-user-ID till 0, men inte ger några kapaciteter till den processen.

Kapacitetsbegränsningsuppsättningen

Kapacitetsbegränsningsuppsättningen är en säkerhetsmekanism som kan användas för att begränsa de kapaciteter som kan erhållas under en execve(2). Begränsningsuppsättningen används på följande sätt:

  • Under en execve(2) OCH:as kapacitetsbegränsningsuppsättningen med filens tillåtna kapacitetsuppsättning, och resultatet av denna operation tilldelas trådens tillåtna kapacitetsuppsättning. Kapacitetsbegränsningsuppsättningen sätter således en gräns för de tillåtna kapaciteter som kan beviljas av en körbar fil.
  • (Sedan Linux 2.6.25) Kapacitetsbegränsningsuppsättningen fungerar som en begränsande överuppsättning för de kapaciteter som en tråd kan lägga till i sin ärftliga uppsättning med hjälp av capset(2). Detta innebär att om en kapacitet inte finns i begränsningsuppsättningen, kan en tråd inte lägga till denna kapacitet till sin ärftliga uppsättning, även om den fanns i dess tillåtna kapaciteter, och kan därmed inte ha denna kapacitet bevarad i sin tillåtna uppsättning när den execve(2):ar en fil som har kapaciteten i sin ärftliga uppsättning.

Observera att begränsningsuppsättningen maskerar filens tillåtna kapaciteter, men inte de ärftliga kapaciteterna. Om en tråd behåller en kapacitet i sin ärftliga uppsättning som inte finns i dess begränsningsuppsättning, kan den fortfarande få den kapaciteten i sin tillåtna uppsättning genom att exekvera en fil som har kapaciteten i sin ärftliga uppsättning.

Beroende på kärnversionen är kapacitetsbegränsningsuppsättningen antingen en systemomfattande attribut eller en attribut per process.

Kapacitetsbegränsningsuppsättning från och med Linux 2.6.25

Från och med Linux 2.6.25 är kapacitetsbegränsningsuppsättningen en attribut per tråd. (Den systemomfattande kapacitetsbegränsningsuppsättningen som beskrivs nedan finns inte längre.)

Begränsningsuppsättningen ärvs vid fork(2) från trådens förälder och bevaras över en execve(2).

En tråd kan ta bort kapaciteter från sin kapacitetsbegränsningsuppsättning med hjälp av prctl(2) PR_CAPBSET_DROP-operationen, förutsatt att den har CAP_SETPCAP-kapaciteten. När en kapacitet har tagits bort från begränsningsuppsättningen kan den inte återställas till den uppsättningen. En tråd kan avgöra om en kapacitet finns i sin begränsningsuppsättning med hjälp av prctl(2) PR_CAPBSET_READ-operationen.

Att ta bort kapaciteter från begränsningsuppsättningen stöds endast om filkapaciteter är kompilerade in i kärnan. Före Linux 2.6.33 var filkapaciteter en valfri funktion som kunde konfigureras via CONFIG_SECURITY_FILE_CAPABILITIES-alternativet i kärnkonfigurationen. Sedan Linux 2.6.33 har konfigurationsalternativet tagits bort och filkapaciteter är alltid en del av kärnan. När filkapaciteter är kompilerade in i kärnan, börjar init-processen (förfadern till alla processer) med en fullständig begränsningsuppsättning. Om filkapaciteter inte är kompilerade in i kärnan, börjar init med en fullständig begränsningsuppsättning minus CAP_SETPCAP, eftersom denna kapacitet har en annan betydelse när det inte finns några filkapaciteter.

Att ta bort en kapacitet från begränsningsuppsättningen tar inte bort den från trådens ärftliga uppsättning. Men det förhindrar att kapaciteten läggs tillbaka i trådens ärftliga uppsättning i framtiden.

Kapacitetsbegränsningsuppsättning före Linux 2.6.25

Före Linux 2.6.25 är kapacitetsbegränsningsuppsättningen en systemomfattande attribut som påverkar alla trådar på systemet. Begränsningsuppsättningen är tillgänglig via filen /proc/sys/kernel/cap-bound. (Förvirrande nog uttrycks denna bitmaskparameter som ett signerat decimaltal i /proc/sys/kernel/cap-bound.)

Endast init-processen kan ställa in kapaciteter i kapacitetsbegränsningsuppsättningen; utöver det kan superanvändaren (mer exakt: en process med CAP_SYS_MODULE-kapaciteten) endast rensa kapaciteter från denna uppsättning.

På ett standardsystem maskerar kapacitetsbegränsningsuppsättningen alltid bort CAP_SETPCAP-kapaciteten. För att ta bort denna begränsning (farligt!), modifiera definitionen av CAP_INIT_EFF_SET i include/linux/capability.h och bygg om kärnan.

Funktionen för systemomfattande kapacitetsbegränsningsuppsättning lades till i Linux 2.2.11.

Effekt av användar-ID-ändringar på kapaciteter

För att bevara de traditionella semantikerna för övergångar mellan 0 och icke-noll användar-ID:n gör kärnan följande ändringar i en tråds kapacitetsuppsättningar vid ändringar av trådens verkliga, effektiva, sparade och filsystemets användar-ID:n (med setuid(2), setresuid(2) eller liknande):

  • Om en eller flera av de verkliga, effektiva eller sparade uppsättningarna av användar-ID:n tidigare var 0, och som ett resultat av användar-ID-ändringarna alla dessa ID:n har ett icke-nollvärde, rensas alla kapaciteter från de tillåtna, effektiva och omgivande kapacitetsuppsättningarna.
  • Om det effektiva användar-ID:t ändras från 0 till icke-noll, rensas alla kapaciteter från den effektiva uppsättningen.
  • Om det effektiva användar-ID:t ändras från icke-noll till 0, kopieras den tillåtna uppsättningen till den effektiva uppsättningen.
  • Om filsystemets användar-ID ändras från 0 till icke-noll (se setfsuid(2)), rensas följande kapaciteter från den effektiva uppsättningen: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (sedan Linux 2.6.30), CAP_MAC_OVERRIDE och CAP_MKNOD (sedan Linux 2.6.30). Om filsystemets UID ändras från icke-noll till 0, aktiveras någon av dessa kapaciteter som är aktiverade i den tillåtna uppsättningen i den effektiva uppsättningen.

Om en tråd som har ett 0-värde för en eller flera av sina användar-ID:n vill förhindra att dess tillåtna kapacitetsuppsättning rensas när den återställer alla sina användar-ID:n till icke-nollvärden, kan den göra det genom att använda SECBIT_KEEP_CAPS securebits-flaggan som beskrivs nedan.

Programmatisk justering av kapacitetsuppsättningar

En tråd kan hämta och ändra sina tillåtna, effektiva och ärftliga kapacitetsuppsättningar med hjälp av systemanropen capget(2) och capset(2). Emellertid är användningen av cap_get_proc(3) och cap_set_proc(3), båda tillhandahållna i libcap-paketet, att föredra för detta ändamål. Följande regler styr ändringar av trådens kapacitetsuppsättningar:

  • Om anroparen inte har CAP_SETPCAP-kapaciteten måste den nya ärftliga uppsättningen vara en delmängd av kombinationen av de befintliga ärftliga och tillåtna uppsättningarna.
  • (Sedan Linux 2.6.25) Den nya ärftliga uppsättningen måste vara en delmängd av kombinationen av den befintliga ärftliga uppsättningen och kapacitetsbegränsningsuppsättningen.
  • Den nya tillåtna uppsättningen måste vara en delmängd av den befintliga tillåtna uppsättningen (dvs. det är inte möjligt att skaffa tillåtna kapaciteter som tråden inte för närvarande har).
  • Den nya effektiva uppsättningen måste vara en delmängd av den nya tillåtna uppsättningen.

Securebits-flaggorna: etablera en miljö endast för kapaciteter

Från och med Linux 2.6.26, och med en kärna där filkapaciteter är aktiverade, implementerar Linux en uppsättning per tråd securebits-flaggor som kan användas för att inaktivera särskild hantering av kapaciteter för UID 0 (root). Dessa flaggor är följande:

SECBIT_KEEP_CAPS

Att ställa in denna flagga tillåter en tråd som har en eller flera 0 UID:n att behålla kapaciteter i sin tillåtna uppsättning när den byter alla sina UID:n till icke-nollvärden. Om denna flagga inte är inställd, orsakar en sådan UID-omkoppling att tråden förlorar alla tillåtna kapaciteter. Denna flagga rensas alltid vid en execve(2).

Observera att även med SECBIT_KEEP_CAPS-flaggan inställd, rensas trådens effektiva kapaciteter när den byter sitt effektiva UID till ett icke-nollvärde. Men om tråden har ställt in denna flagga och dess effektiva UID redan är icke-noll, och tråden därefter byter alla andra UID:n till icke-nollvärden, kommer de effektiva kapaciteterna inte att rensas.

Inställningen av SECBIT_KEEP_CAPS-flaggan ignoreras om SECBIT_NO_SETUID_FIXUP-flaggan är inställd. (Den senare flaggan ger en övergripande effekt av den tidigare flaggan.)

Denna flagga ger samma funktionalitet som den äldre prctl(2) PR_SET_KEEPCAPS-operationen.

SECBIT_NO_SETUID_FIXUP

Att ställa in denna flagga stoppar kärnan från att justera processens tillåtna, effektiva och omgivande kapacitetsuppsättningar när trådens effektiva och filsystemets UID:n byts mellan noll och icke-nollvärden. Se Effekt av användar-ID-ändringar på kapaciteter ovan.

SECBIT_NOROOT

Om denna bit är inställd, beviljar inte kärnan kapaciteter när ett set-user-ID-root-program exekveras, eller när en process med ett effektivt eller verkligt UID på 0 anropar execve(2). (Se Kapaciteter och exekvering av program av root ovan.)

SECBIT_NO_CAP_AMBIENT_RAISE

Att ställa in denna flagga tillåter inte höjning av omgivande kapaciteter via prctl(2) PR_CAP_AMBIENT_RAISE-operationen.

Varje av ovanstående "bas"-flaggor har en medföljande "låst" flagga. Att ställa in någon av de "låsta" flaggorna är oåterkalleligt och förhindrar ytterligare ändringar av motsvarande "bas"-flagga. De låsta flaggorna är: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED och SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED.

Securebits-flaggorna kan modifieras och hämtas med hjälp av prctl(2) PR_SET_SECUREBITS och PR_GET_SECUREBITS-operationerna. CAP_SETPCAP-kapaciteten krävs för att modifiera flaggorna. Observera att SECBIT_*-konstanterna endast är tillgängliga efter att ha inkluderat header-filen <linux/securebits.h>.

Securebits-flaggorna ärvs av barnprocesser. Under en execve(2) bevaras alla flaggor, förutom SECBIT_KEEP_CAPS som alltid rensas.

En applikation kan använda följande anrop för att låsa sig själv och alla dess ättlingar i en miljö där det enda sättet att få kapaciteter är genom att exekvera ett program med associerade filkapaciteter:

```c prctl(PR_SET_SECUREBITS, 

     /* SECBIT_KEEP_CAPS off */
     SECBIT_KEEP_CAPS_LOCKED |
     SECBIT_NO_SETUID_FIXUP |
     SECBIT_NO_SETUID_FIXUP_LOCKED |
     SECBIT_NOROOT |
     SECBIT_NOROOT_LOCKED);

/* Att ställa in/låsa SECBIT_NO_CAP_AMBIENT_RAISE 

  är inte nödvändigt */

```

Per-användarnamnsutrymme "set-user-ID-root"-program

Ett set-user-ID-program vars UID matchar UID som skapade ett användarnamnsutrymme kommer att conferera kapaciteter i processens tillåtna och effektiva uppsättningar när det exekveras av någon process inuti det namnutrymmet eller något underliggande användarnamnsutrymme.

Reglerna om transformation av processens kapaciteter under execve(2) är exakt som beskrivs i Transformation av kapaciteter under execve() och Kapaciteter och exekvering av program av root ovan, med skillnaden att i den senare undersektionen är "root" UID:t för skaparen av användarnamnsutrymmet.

Namnutrymmesfilkapaciteter

Traditionella (dvs. version 2) filkapaciteter associerar endast en uppsättning kapacitetsmaskor med en binär körbar fil. När en process exekverar en binär med sådana kapaciteter, får den associerade kapaciteter (inom sitt användarnamnsutrymme) enligt de regler som beskrivs i Transformation av kapaciteter under execve() ovan.

Eftersom version 2 filkapaciteter beviljar kapaciteter till den exekverande processen oavsett vilket användarnamnsutrymme den befinner sig i, tillåts endast privilegierade processer att associera kapaciteter med en fil. Här betyder "privilegierad" en process som har CAP_SETFCAP-kapaciteten i det användarnamnsutrymme där filsystemet monterades (normalt det initiala användarnamnsutrymmet). Denna begränsning gör filkapaciteter oanvändbara för vissa användningsfall. Till exempel kan det i användarnamnsutrymmesbehållare vara önskvärt att kunna skapa en binär som beviljar kapaciteter endast till processer som exekveras inuti den behållaren, men inte till processer som exekveras utanför behållaren.

Linux 4.14 lade till så kallade namnutrymmesfilkapaciteter för att stödja sådana användningsfall. Namnutrymmesfilkapaciteter registreras som version 3 (dvs. VFS_CAP_REVISION_3) security.capability-utökade attribut. Ett sådant attribut skapas automatiskt under de omständigheter som beskrivs i Filkapacitetsutökat attribut versionering ovan. När ett version 3 security.capability-utökat attribut skapas, registrerar kärnan inte bara kapacitetsmaskorna i det utökade attributet, utan också namnutrymmets rotanvändar-ID.

Precis som med en binär som har VFS_CAP_REVISION_2 filkapaciteter, beviljar en binär med VFS_CAP_REVISION_3 filkapaciteter kapaciteter till en process under execve(2). Men kapaciteter är endast beviljade om binären exekveras av en process som befinner sig i ett användarnamnsutrymme vars UID 0 mappar till rotanvändar-ID:t som sparas i det utökade attributet, eller när den exekveras av en process som befinner sig i en underliggande sådan namnutrymme.

Interaktion med användarnamnsutrymmen

För ytterligare information om interaktionen mellan kapaciteter och användarnamnsutrymmen, se user_namespaces(7).

STANDARDER

Inga standarder styr kapaciteter, men Linux-kapacitetsimplementeringen är baserad på det tillbakadragna POSIX.1e-utkastet ⟨https://archive.org/details/posix_1003.1e-990310⟩.

ANMÄRKNINGAR

När du försöker strace(1) binärer som har kapaciteter (eller set-user-ID-root-binärer) kan du finna -u <användarnamn>-alternativet användbart. Något i stil med:

``` $ sudo strace -o trace.log -u ceci ./myprivprog ```

Från Linux 2.5.27 till Linux 2.6.26 var kapaciteter en valfri kärnkomponent och kunde aktiveras/inaktiveras via CONFIG_SECURITY_CAPABILITIES-kärnkonfigurationsalternativet.

Filen /proc/pid/task/TID/status kan användas för att visa kapacitetsuppsättningarna för en tråd. Filen /proc/pid/status visar kapacitetsuppsättningarna för en processens huvudtråd. Före Linux 3.8 visades icke-existerande kapaciteter som aktiverade (1) i dessa uppsättningar. Sedan Linux 3.8 visas alla icke-existerande kapaciteter (över CAP_LAST_CAP) som inaktiverade (0).

Libcap-paketet tillhandahåller en svit av rutiner för att ställa in och hämta kapaciteter som är mer bekväma och mindre benägna att förändras än gränssnittet som tillhandahålls av capset(2) och capget(2). Detta paket tillhandahåller också programmen setcap(8) och getcap(8). Det kan hittas på ⟨https://git.kernel.org/pub/scm/libs/libcap/libcap.git/refs/⟩.

Före Linux 2.6.24, och från Linux 2.6.24 till Linux 2.6.32 om filkapaciteter inte är aktiverade, kan en tråd med CAP_SETPCAP-kapaciteten manipulera kapaciteterna hos andra trådar än sig själv. Men detta är endast teoretiskt möjligt, eftersom ingen tråd någonsin har CAP_SETPCAP i någon av dessa fall:

  • I implementeringen före 2.6.25 maskerar den systemomfattande kapacitetsbegränsningsuppsättningen, /proc/sys/kernel/cap-bound, alltid bort CAP_SETPCAP-kapaciteten, och detta kan inte ändras utan att modifiera kärnkällan och bygga om kärnan.
  • Om filkapaciteter är inaktiverade (dvs. kärnans CONFIG_SECURITY_FILE_CAPABILITIES-alternativ är inaktiverat), börjar init med att ha CAP_SETPCAP-kapaciteten borttagen från sin per-process begränsningsuppsättning, och den begränsningsuppsättningen ärvs av alla andra processer som skapas på systemet.

SE OCKSÅ

capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8), filecap(8), getcap(8), getpcaps(8), netcap(8), pscap(8), setcap(8)

include/linux/capability.h i Linux-kärnans källkodsträd

COLOFON

Denna sida är en del av man-pages (Linux-kärnan och C-bibliotekets användarutrymmesgränssnittsdokumentation) projektet. Information om projektet kan hittas på ⟨https://www.kernel.org/doc/man-pages/⟩. Om du har en felrapport för denna manualsida, se ⟨https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING⟩. Denna sida erhölls från tarbollen man-pages-6.9.1.tar.gz hämtad från ⟨https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/⟩ den 2024-06-26. Om du upptäcker några renderingsproblem i denna HTML-version av sidan, eller om du tror att det finns en bättre eller mer uppdaterad källa för sidan, eller om du har korrigeringar eller förbättringar av informationen i denna COLOFON (som inte är en del av den ursprungliga manualsidan), skicka ett mail till man-pages@man7.org

Linux man-pages 6.9.1 2024-06-13 Capabilities(7)

Sidor som refererar till denna sida: capsh(1), homectl(1), setpriv(1), systemd-analyze(1), systemd-nspawn(1), adjtimex(2), capget(2), clone(2), execve(2), fcntl(2), fork(2), getgroups(2), getpriority(2), getrlimit(2), gettimeofday(2), intro(2), ioperm(2), iopl(2), ioprio_set(2), keyctl(2), kill(2), mlock(2), mount_setattr(2), msgctl(2), msgget(2), msgop(2), nice(2), pciconfig_read(2), PR_GET_KEEPCAPS(2const), PR_GET_SECUREBITS(2const), process_madvise(2), PR_SET_DUMPABLE(2const), PR_SET_KEEPCAPS(2const), PR_SET_PDEATHSIG(2const), PR_SET_SECUREBITS(2const), ptrace(2), reboot(2), request_key(2), sched_setaffinity(2), sched_setattr(2), sched_setparam(2), sched_setscheduler(2), semctl(2), semget(2), semop(2), seteuid(2), setfsgid(2), setfsuid(2), setgid(2), setresuid(2), setreuid(2), setuid(2), shmctl(2), shmget(2), shmop(2), spu_create(2), spu_run(2), stat(2), statx(2), stime(2), syslog(2), uselib(2), vhangup(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_iab(3), cap_init(3), cap_launch(3), capng_apply(3), capng_apply_caps_fd(3), capng_capability_to_name(3), capng_change_id(3), capng_clear(3), capng_fill(3), capng_get_caps_fd(3), capng_get_caps_process(3), capng_get_rootid(3), capng_have_capabilities(3), capng_have_capability(3), capng_lock(3), capng_name_to_capability(3), capng_print_caps_numeric(3), capng_print_caps_text(3), capng_restore_state(3), capng_save_state(3), capng_setpid(3), capng_set_rootid(3), capng_update(3), capng_updatev(3), getauxval(3), getenv(3), intro(3), killpg(3), libcap(3), pthread_create(3), sd_bus_add_object(3), sd_bus_creds_get_pid(3), sd_bus_query_sender_creds(3), core(5), lxc.container.conf(5), proc_pid_status(5), proc_sys_kernel(5), systemd.exec(5), systemd.nspawn(5), systemd-system.conf(5), systemd.unit(5), arp(7), credentials(7), ddp(7), ip(7), libdrop_ambient(7), namespaces(7), netdevice(7), netlink(7), packet(7), path_resolution(7), pid_namespaces(7), pthreads(7), raw(7), sched(7), socket(7), spufs(7), systemd.journal-fields(7), unix(7), user_namespaces(7), vsock(7), xattr(7), captest(8), captree(8), filecap(8), getcap(8), getpcaps(8), ip-vrf(8), ld.so(8), mount.fuse3(8), netcap(8), pam_systemd(8), pscap(8), setcap(8)


Sidslut

Orginalhemsidan på Engelska :https://man7.org/linux/man-pages/man7/capabilities.7.html

Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till PC Service som har sponsrat Linux.se med webbhotell.

Hämtad från "https://wiki.linux.se/index.php?title=capabilities(7)&oldid=6236"