Administrere brukere og grupper, filtillatelser og attributter og aktivere sudo-tilgang på kontoer - del 8

I august i fjor startet Linux Foundation LFCS-sertifiseringen (Linux Foundation Certified Sysadmin), et helt nytt program hvis formål er å la enkeltpersoner overalt og hvor som helst ta en eksamen for å bli sertifisert i grunnleggende til middels operasjonell støtte for Linux-systemer, som inkluderer støtte for kjørende systemer og tjenester, sammen med generell overvåking og analyse, pluss intelligent beslutningstaking for å kunne bestemme når det er nødvendig å eskalere problemer til høyere nivå supportteam.

Ta en rask titt på følgende video som beskriver en introduksjon til Linux Foundation Certification Program.

Denne artikkelen er del 8 av en lang serie med 10 veiledninger, her i denne delen vil vi veilede deg om hvordan du administrerer bruker- og gruppertillatelser i Linux-systemet, som kreves for LFCS-sertifiseringseksamenen.

Siden Linux er et flerbrukeroperativsystem (ved at det lar flere brukere på forskjellige datamaskiner eller terminaler få tilgang til et enkelt system), må du vite hvordan du utfører effektiv brukeradministrasjon: hvordan legge til, redigere, suspendere eller slette brukerkontoer, sammen med å gi dem de nødvendige tillatelsene til å utføre de tildelte oppgavene.

Legge til brukerkontoer

For å legge til en ny brukerkonto, kan du kjøre en av følgende to kommandoer som root.

adduser [new_account]
useradd [new_account]

Når en ny brukerkonto legges til systemet, utføres følgende operasjoner.

1. Hjemmekatalogen hans/hennes er opprettet (/home/brukernavn som standard).

2. Følgende skjulte filer kopieres til brukerens hjemmekatalog, og vil bli brukt til å gi miljøvariabler for brukerøkten hans/hennes.

.bash_logout
.bash_profile
.bashrc

3. En e-postkø opprettes for brukeren på /var/spool/mail/brukernavn.

4. En gruppe opprettes og gis samme navn som den nye brukerkontoen.

Forstå /etc/passwd

Den fullstendige kontoinformasjonen lagres i filen /etc/passwd. Denne filen inneholder en post per systembrukerkonto og har følgende format (felt er avgrenset med kolon).

[username]:[x]:[UID]:[GID]:[Comment]:[Home directory]:[Default shell]

Feltene [brukernavn] og [Kommentar] er selvforklarende.
x i det andre feltet indikerer at kontoen er beskyttet av et skyggelagt passord (i /etc/shadow), som er nødvendig for å logge på som [brukernavn] .
Feltene [UID] og [GID] er heltall som representerer henholdsvis bruker-ID-en og den primære gruppe-ID-en som [brukernavn] tilhører .
[Hjemmekatalog] indikerer den absolutte banen til [brukernavn] sin hjemmekatalog, og
[Standard-skall] er skallet som vil bli gjort tilgjengelig for denne brukeren når han eller hun logger på systemet.

Forstå /etc/group

Gruppeinformasjon lagres i filen /etc/group. Hver post har følgende format.

[Group name]:[Group password]:[GID]:[Group members]

[Gruppenavn] er navnet på gruppen.
En x i [Gruppepassord] indikerer at gruppepassord ikke brukes.
[GID]: samme som i /etc/passwd.
[Gruppemedlemmer]: en kommadelt liste over brukere som er medlemmer av [Gruppenavn].

Etter å ha lagt til en konto, kan du redigere følgende informasjon (for å nevne noen felt) ved å bruke usermod-kommandoen, hvis grunnleggende syntaks for usermod er som følger.

usermod [options] [username]

Angi utløpsdato for en konto

Bruk –utløpsdato-flagget etterfulgt av en dato i formatet ÅÅÅÅ-MM-DD.

usermod --expiredate 2014-10-30 tecmint

Legger til brukeren i tilleggsgrupper

Bruk de kombinerte alternativene -aG eller –legg til –grupper, etterfulgt av en kommadelt liste over grupper.

usermod --append --groups root,users tecmint

Endre standardplasseringen til brukerens hjemmekatalog

Bruk alternativene -d eller –home, etterfulgt av den absolutte banen til den nye hjemmekatalogen.

usermod --home /tmp tecmint

Endring av skallet brukeren vil bruke som standard

Bruk –shell, etterfulgt av banen til det nye skallet.

usermod --shell /bin/sh tecmint

Viser gruppene en bruker er medlem av

groups tecmint
id tecmint

La oss nå utføre alle kommandoene ovenfor på en gang.

usermod --expiredate 2014-10-30 --append --groups root,users --home /tmp --shell /bin/sh tecmint

I eksemplet ovenfor vil vi sette utløpsdatoen for tecmint-brukerkontoen til 30. oktober 2014. Vi vil også legge til kontoen i root- og brukergruppen. Til slutt vil vi sette sh som standard skall og endre plasseringen av hjemmekatalogen til /tmp:

Les også:

15 useradd Kommandoeksempler i Linux
15 usermod Kommandoeksempler i Linux

For eksisterende kontoer kan vi også gjøre følgende.

Deaktiverer kontoen ved å låse passord

Bruk -L (store bokstaver L) eller –lås for å låse en brukers passord.

usermod --lock tecmint

Låser opp brukerpassord

Bruk alternativet –u eller –unlock for å låse opp en brukers passord som tidligere var blokkert.

usermod --unlock tecmint

Opprette en ny gruppe for lese- og skrivetilgang til filer som må åpnes av flere brukere

Kjør følgende rekke med kommandoer for å nå målet.

groupadd common_group # Add a new group
chown :common_group common.txt # Change the group owner of common.txt to common_group
usermod -aG common_group user1 # Add user1 to common_group
usermod -aG common_group user2 # Add user2 to common_group
usermod -aG common_group user3 # Add user3 to common_group

Sletter en gruppe

Du kan slette en gruppe med følgende kommando.

groupdel [group_name]

Hvis det er filer som eies av gruppenavn, vil de ikke bli slettet, men gruppeeieren vil bli satt til GID til gruppen som ble slettet.

Linux-filtillatelser

I tillegg til de grunnleggende lese-, skrive- og utføringstillatelsene som vi diskuterte i Arkiveringsverktøy og innstilling av filattributter – del 3 av denne serien, er det andre mindre brukte (men ikke mindre viktige) tillatelsesinnstillinger, noen ganger referert til som «spesielle tillatelser ".

Som de grunnleggende tillatelsene diskutert tidligere, er de satt ved hjelp av en oktal fil eller gjennom en bokstav (symbolsk notasjon) som indikerer typen tillatelse.

Sletting av brukerkontoer

Du kan slette en konto (sammen med hjemmekatalogen, hvis den eies av brukeren, og alle filene som ligger der, og også e-postkøen) ved å bruke userdel-kommandoen med –remove alternativet.

userdel --remove [username]

Konsernledelse

Hver gang en ny brukerkonto legges til systemet, opprettes en gruppe med samme navn med brukernavnet som eneste medlem. Andre brukere kan legges til i gruppen senere. Et av formålene med grupper er å implementere en enkel tilgangskontroll til filer og andre systemressurser ved å angi de riktige tillatelsene for disse ressursene.

Anta for eksempel at du har følgende brukere.

bruker1 (primærgruppe: bruker1)
bruker2 (primærgruppe: bruker2)
bruker3 (primærgruppe: bruker3)

Alle trenger lese og skrive tilgang til en fil kalt common.txt som ligger et sted på ditt lokale system, eller kanskje på en nettverksressurs som bruker1 har opprettet. Du kan bli fristet til å gjøre noe som

chmod 660 common.txt
OR
chmod u=rw,g=rw,o= common.txt [notice the space between the last equal sign and the file name]

Dette vil imidlertid bare gi lese og skrive tilgang til eieren av filen og til de brukerne som er medlemmer av gruppens eier av filen (bruker1 i dette tilfellet). Igjen, du kan bli fristet til å legge til bruker2 og bruker3 i gruppen bruker1, men det vil også gi dem tilgang til resten av filene som eies av bruker bruker1 og gruppe bruker1.

Det er her grupper kommer godt med, og her er hva du bør gjøre i et tilfelle som dette.

Forstå Setuid

Når setuid-tillatelsen brukes på en kjørbar fil, arver en bruker som kjører programmet de effektive rettighetene til programmets eier. Siden denne tilnærmingen med rimelighet kan skape sikkerhetsproblemer, må antallet filer med setuid-tillatelse holdes på et minimum. Du vil sannsynligvis finne programmer med dette tillatelsessettet når en systembruker trenger tilgang til en fil som eies av root.

Oppsummert er det ikke bare at brukeren kan kjøre den binære filen, men også at han kan gjøre det med roots privilegier. La oss for eksempel sjekke tillatelsene til /bin/passwd. Denne binærfilen brukes til å endre passordet til en konto, og endrer /etc/shadow-filen. Superbrukeren kan endre passordet til hvem som helst, men alle andre brukere skal bare kunne endre sitt eget.

Derfor bør enhver bruker ha tillatelse til å kjøre /bin/passwd, men bare root vil kunne spesifisere en konto. Andre brukere kan bare endre sine tilsvarende passord.

Forstå Setgid

Når setgid-biten er satt, blir den effektive GID for den virkelige brukeren til gruppeeieren. Dermed kan enhver bruker få tilgang til en fil under privilegiene gitt til gruppeeieren av en slik fil. I tillegg, når setgid-biten er satt på en katalog, arver nyopprettede filer den samme gruppen som katalogen, og nyopprettede underkataloger vil også arve setgid-biten til overordnet katalog. Du vil mest sannsynlig bruke denne tilnærmingen når medlemmer av en bestemt gruppe trenger tilgang til alle filene i en katalog, uavhengig av fileierens primære gruppe.

chmod g+s [filename]

For å sette setgid i oktal form, sett tallet 2 foran gjeldende (eller ønskede) grunnleggende tillatelser.

chmod 2755 [directory]

Sette SETGID i en katalog

Forstå Sticky Bit

Når "sticky bit " er satt på filer, ignorerer Linux det, mens det for kataloger har effekten av å hindre brukere i å slette eller til og med gi nytt navn til filene den inneholder med mindre brukeren eier katalogen, fil, eller er root.

chmod o+t [directory]

For å sette sticky bit i oktal form, sett tallet 1 foran gjeldende (eller ønskede) grunnleggende tillatelser.

chmod 1755 [directory]

Uten den klebrige biten kan alle som kan skrive til katalogen slette eller endre navn på filer. Av den grunn er den klebrige biten ofte funnet i kataloger, for eksempel /tmp, som er skrivbare i verden.

Spesielle Linux-filattributter

Det er andre attributter som muliggjør ytterligere begrensninger på operasjonene som er tillatt på filer. For eksempel forhindre at filen blir endret navn, flyttet, slettet eller til og med endret. De er satt med chattr-kommandoen og kan sees ved hjelp av lsattr-verktøyet, som følger.

chattr +i file1
chattr +a file2

Etter å ha utført disse to kommandoene, vil fil1 være uforanderlig (noe som betyr at den ikke kan flyttes, gi nytt navn, endres eller slettes), mens fil2 vil gå inn i bare vedleggsmodus (kan bare være åpne i tilleggsmodus for skriving).

Få tilgang til root-kontoen og bruke sudo

En av måtene brukere kan få tilgang til root-kontoen på er ved å skrive.

su

og skriv deretter inn roots passord.

Hvis autentiseringen lykkes, vil du bli logget på som root med gjeldende arbeidskatalog som den samme som du var før. Hvis du ønsker å bli plassert i roots hjemmekatalog i stedet, kjør.

su -

og skriv deretter inn roots passord.

Prosedyren ovenfor krever at en normal bruker kjenner til roots passord, noe som utgjør en alvorlig sikkerhetsrisiko. Av den grunn kan systemadministratoren konfigurere sudo-kommandoen til å tillate en vanlig bruker å utføre kommandoer som en annen bruker (vanligvis superbrukeren) på en veldig kontrollert og begrenset måte. Dermed kan begrensninger settes på en bruker slik at han kan kjøre en eller flere spesifikke privilegerte kommandoer og ingen andre.

Les også: Forskjellen mellom su og sudo-bruker

For å autentisere med sudo, bruker brukeren sitt eget passord. Etter å ha skrevet inn kommandoen, vil vi bli bedt om passordet vårt (ikke superbrukerens), og hvis autentiseringen lykkes (og hvis brukeren har fått rettigheter til å kjøre kommandoen), utføres den angitte kommandoen.

For å gi tilgang til sudo, må systemadministratoren redigere /etc/sudoers-filen. Det anbefales at denne filen redigeres ved å bruke visudo-kommandoen i stedet for å åpne den direkte med et tekstredigeringsprogram.

visudo

Dette åpner /etc/sudoers-filen ved å bruke vim (du kan følge instruksjonene gitt i Installer og bruk vim som redaktør – del 2 av denne serien for å redigere filen).

Dette er de mest relevante linjene.

Defaults    secure_path="/usr/sbin:/usr/bin:/sbin"
root        ALL=(ALL) ALL
tecmint     ALL=/bin/yum update
gacanepa    ALL=NOPASSWD:/bin/updatedb
%admin      ALL=(ALL) ALL

La oss se nærmere på dem.

Defaults    secure_path="/usr/sbin:/usr/bin:/sbin:/usr/local/bin"

Denne linjen lar deg spesifisere katalogene som skal brukes for sudo, og brukes til å forhindre bruk av brukerspesifikke kataloger, som kan skade systemet.

De neste linjene brukes til å spesifisere tillatelser.

root        ALL=(ALL) ALL

Det første søkeordet ALL indikerer at denne regelen gjelder for alle verter.
Den andre ALLE indikerer at brukeren i den første kolonnen kan kjøre kommandoer med rettighetene til enhver bruker.
Den tredje ALL betyr at enhver kommando kan kjøres.

tecmint     ALL=/bin/yum update

Hvis ingen bruker er spesifisert etter =-tegnet, antar sudo rotbrukeren. I dette tilfellet vil brukeren tecmint kunne kjøre yum update som root.

gacanepa    ALL=NOPASSWD:/bin/updatedb

NOPASSWD-direktivet lar brukeren gacanepa kjøre /bin/updatedb uten å måtte angi passordet sitt.

%admin      ALL=(ALL) ALL

%-tegnet indikerer at denne linjen gjelder en gruppe kalt «admin ». Betydningen av resten av linjen er identisk med betydningen til en vanlig bruker. Dette betyr at medlemmer av gruppen «admin» kan kjøre alle kommandoer som en hvilken som helst bruker på alle verter.

For å se hvilke privilegier som gis til deg av sudo, bruk "-l "-alternativet for å liste dem opp.

PAM (pluggbare autentiseringsmoduler)

Plugbare autentiseringsmoduler (PAM) tilbyr fleksibiliteten til å angi et spesifikt autentiseringsskjema på basis av applikasjoner og/eller tjenester ved bruk av moduler. Dette verktøyet som er tilstede på alle moderne Linux-distribusjoner, overvant problemet ofte møtt av utviklere i de tidlige dagene av Linux, da hvert program som krevde autentisering måtte kompileres spesielt for å vite hvordan de skulle få den nødvendige informasjonen.

For eksempel, med PAM, spiller det ingen rolle om passordet ditt er lagret i /etc/shadow eller på en separat server i nettverket ditt.

For eksempel, når påloggingsprogrammet trenger å autentisere en bruker, gir PAM dynamisk biblioteket som inneholder funksjonene for riktig autentiseringsskjema. Dermed er det enkelt å endre autentiseringsskjemaet for påloggingsapplikasjonen (eller et hvilket som helst annet program som bruker PAM), siden det bare innebærer å redigere en konfigurasjonsfil (mest sannsynlig en fil oppkalt etter applikasjonen, plassert inne i /etc/pam.d , og mindre sannsynlig i /etc/pam.conf).

Filer inne i /etc/pam.d indikerer hvilke applikasjoner som bruker PAM naturlig. I tillegg kan vi se om en bestemt applikasjon bruker PAM ved å sjekke om PAM-biblioteket (libpam) er koblet til det:


ldd $(which login) | grep libpam # login uses PAM
ldd $(which top) | grep libpam # top does not use PAM

I bildet ovenfor kan vi se at libpam har blitt koblet til påloggingsapplikasjonen. Dette er fornuftig siden denne applikasjonen er involvert i driften av systembrukerautentisering, mens topp ikke gjør det.

La oss undersøke PAM-konfigurasjonsfilen for passwd – ja, det velkjente verktøyet for å endre brukerens passord. Den ligger på /etc/pam.d/passwd:


cat /etc/passwd

Den første kolonnen angir type autentisering som skal brukes med modulstien (tredje kolonne). Når en bindestrek vises foran typen, vil ikke PAM registrere til systemloggen hvis modulen ikke kan lastes fordi den ikke ble funnet i systemet.

Følgende autentiseringstyper er tilgjengelige:

konto: denne modultypen sjekker om brukeren eller tjenesten har oppgitt gyldig legitimasjon for å autentisere.
auth: denne modultypen bekrefter at brukeren er den han/hun utgir seg for å være og gir eventuelle nødvendige rettigheter.
passord: Denne modultypen lar brukeren eller tjenesten oppdatere passordet sitt.
session: denne modultypen indikerer hva som bør gjøres før og/eller etter at autentiseringen lykkes.

Den andre kolonnen (kalt control) angir hva som skal skje hvis autentiseringen med denne modulen mislykkes:

krav: Hvis autentiseringen via denne modulen mislykkes, vil generell autentisering bli avvist umiddelbart.
required er lik nødvendig, selv om alle andre oppførte moduler for denne tjenesten vil bli kalt opp før godkjenning nektes.
tilstrekkelig: hvis autentiseringen via denne modulen mislykkes, vil PAM fortsatt gi autentisering selv om en tidligere markert som nødvendig mislyktes.
valgfritt: hvis autentiseringen via denne modulen mislykkes eller lykkes, skjer ingenting med mindre dette er den eneste modulen av sin type som er definert for denne tjenesten.
include betyr at linjene av den gitte typen skal leses fra en annen fil.
substack er lik inkluderer, men autentiseringsfeil eller suksesser fører ikke til at hele modulen avsluttes, men bare understakken.

Den fjerde kolonnen, hvis den finnes, viser argumentene som skal sendes til modulen.

De tre første linjene i /etc/pam.d/passwd (vist ovenfor), laster system-auth-modulen for å sjekke at brukeren har oppgitt gyldig legitimasjon (konto) . I så fall lar det ham/henne endre autentiseringstoken (passord) ved å gi tillatelse til å bruke passwd (autentisering).

For eksempel hvis du legger ved


remember=2

til følgende linje


password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok

i /etc/pam.d/system-auth:


password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=2

de to siste hashed-passordene til hver bruker lagres i /etc/security/opasswd slik at de ikke kan gjenbrukes:

Sammendrag

Effektive bruker- og filbehandlingsferdigheter er viktige verktøy for enhver systemadministrator. I denne artikkelen har vi dekket det grunnleggende og håper du kan bruke det som et godt utgangspunkt for å bygge videre på. Legg gjerne igjen kommentarer eller spørsmål nedenfor, så svarer vi raskt.