Безбедност на UNIX-like

оперативните системи

Предавач: доц. д-р Александра Милева

Безбедност на оперативни
системи
Општ шаблон за организација на безбедносните
контроли во повеќето оперативни системи
Информациите за корисниците, заедно со сите негови
привилегии се зачувани во кориснички сметки
(account)
Со идентификација и автентикација се верификува
идентитетот кај корисникот
Дозволите за објектите можат да се постават од
сопственикот или од администраторот
Откривање на неовластени активности
Дневник за следење настани (audit trail)
Инсталација и конфигурација на ОС
Интегритет на ОС
Нека на пример, ОС може да ги спроведе сите потребни
политики за контрола на пристап.
Но, и ОС е објект на контролата на пристап!
На корисниците не треба да им биде дозволено да го
менуваат ОС!
 Корисниците треба да можат да го користат ОС
 Корисниците не би требало да можат да го злоупотребуваат ОС
Два важни концепта за постигнување на овие цели:
 информации за статус (status information)
 контролирано повикување (controlled invocation)
Информации за статус
ОС треба да биде способен да разликува операции “во
име” на ОС и операции “во име на” корисник
Индикатор на состојба (Status flag) овозможува
системот да работи во различни режими
 Motorola 68000 – еден статус бит, кој овозможува разликување
меѓу режим на корисник (user mode) и режим на супервизор
(систем)(supervisor (system) mode)
 Intel 80386 – два статус бита кои резултираат во 4 режими
На пример, да се запрат корисниците од запишување
директно во меморијата и од корумпирање на логичката
податочна структура, ОС може да додели пристап за
пишување во мемориски локации, само ако процесорот
е во супервизорски режим
Контролирано повикување
Корисникот сака да изврши операција за која е
потребен супервизорски режим
Едноставна промена на статусот во супервизорски
режим би ги дала сите привилегии поврзани со овој
режим на корисникот, без никаква контрола за тоа
што всушност прави тој
Пожелно е системот да извршува само
предефинирана група операции во супервизорски
режим, а потоа да се врати во кориснички режим
пред повторно да ја врати контролата на корисникот.
Овој процес се нарекува контролирано повикување.
UNIX
Почетна асемблерска имплементација од страна на Ken
Thompson и Dennis Ritchie (Bell Labs) за PDP-7 и PDP-11
повторно напишан во C во 1973: прв оперативен систем
напишан во јазик на високо ниво
постојана еволуција на различни дијалекти на UNIX и
неговите рутини повеќе од 40 години
Безбедноста не беше примарна дизајнерска цел за
UNIX, доминантни цели беа модуларноста,
преносливоста и ефикасноста
UNIX обезбедува доволно безбедносни механизми кои
мора правилно да се конфигурираат и администрираат
POSIX – ISO стандард
Управители
Корисници и групи
Идентификатори на корисници (User identifiers - UID)
 UID информациите се складирани во /etc/passwd
 nobody – специјален корисник без сопствеништво и припаѓа на
nogroup (GID=216−2 = 65,534)
Идентификатори на групи – (Group identifiers - GID)
 GID информациите се складирани во /etc/group
UID и GID се 16-битни броеви (во модерните системи и
32-битни броеви)
Супер-корисник (root) секогаш има UID 0.
1-99 е резервирано за други предефинирани сметки,
100-999 за системски сметки/групи
Дискреционата контрола на пристап
 Корисникот или неговите процеси може да ги променат дозволите
 Секој програм ги има сите права на неговиот корисник
UNIX автентикација
Login процес
 се стартува во време на бутирање и е во
сопственост на root
 се користат кориснички имиња и лозинки

 на лозинката се применува функција crypt() со

зачувана сол вредност

 резултатот се споредува со вредноста во

датотеката со лозинки
Почетни процеси за корисникот
 се извршува датотеката специфицирана како login
во /etc/passwd
 идентитетот се поставува со login
Информации за кориснички
сметки: /etc/passwd
Username: Password: User ID (UID): Group ID (GID): User ID
info: Home directory: login shell
1. Username: се користи кога корисникот се логира, има должина
од 1–32 знаци
2. Password: ’x’ индицира дека шифрираната лозинка е складирана
во /etc/shadow; најчесто до 8 знаци; празно поле или *
3. Group ID: примарната група на корисникот
4. Home directory: апсолутен пат до директориумот во кој ќе биде
корисникот по логирањето
5. login shell: апсолутен пат до шелот
root:x:0:0:root:/root:/bin/bash
dhcp:x:101:102::/nonexistent:/bin/false
syslog:x:102:103::/home/syslog:/bin/false
mileva:x:1000:1000:Aleksandra Mileva: /home/mileva:/bin/bash
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
Информации за кориснички
сметки
/etc/profile – активности преземени од системот
.profile – други посебни параметри за корисниците
/usr/adm/lastlog – чува последна најава на корисникот
и може да се прикаже на пример со наредбата finger
passwd(1) – наредба за промена на лозинките.
Ефектот на промената може да го потврдите со нова
најава или со su(1)
побезбедните верзии на Unix користат сол за
лозинките или ги чуваат лозинките во скриена
датотека за лозинки, како /.secure/etc/passwd
Датотека со сенка лозинки:
/etc/shadow
1. Username: корисничко име
2. Passwd: хеширана лозинка
3. Last: денови (од Jan 1, 1970) од последна промена на лозинката
4. May: денови пред лозинката да може да се промени, обично 0
5. Must: денови после кои лозинката мора да се промени, дефолт
99999
6. Warn: денови пред истекување на лозинката кога се опоменува
корисникот
7. Expire: денови на оневозможена корисничка сметка, после
истекувањето на лозинката, -1 е за бесконечност
8. Disable: денови (од Jan 1, 1970) на оневозможена корисничка
сметка
9. Reserved

Само root има право да ја прочита!!!

Датотека со сенка лозинки:
/etc/shadow

"NP" или "!" или null – нема лозинка

"LK" или "*" – оневозможена корисничка сметка
"!!" – истечена лозинка

root:!:14118:0:99999:7:::
ana:R,Jll.or6u1e7:10795:0:99999:7:-1:-1:134537220
dejan:Ep6mckrOLChF.:10063:0:99999:7:::
tea:$6$QR3drPrQ$JLolPKyiVuXvea1F2IpbPx9F9PEV0s/IGcNCpm6ZrBA6AFDvwHPQ
G7EsTQHuUqxfCvlsuKRb.O7w5RLPyj8nS/:15119:0:99999:7:::
 Хеширање на лозинки во UNIX
Библиотечна функција crypt(3), која е вклучена и во
програмските јазици како PHP, Perl, Python, Ruby и др.
Се користи за хеширање на лозинката заедно со сол. Солта
може да започнува со $cifra$ и cifra го означува користениот
алгоритам.
За енкодирање на хеш резултатите се користи Modular Crypt
Format (MCF).

$<id>[$<param>=<value>(,<param>=<value>)*][$<salt>[$<hash>]]
id – идентификатор на шемата
param – value – параметри како број на рунди/итерации
salt –енкодирана сол
hash - енкодиран хеш резултат
Хеширање на лозинки во UNIX
Традиционална DES-базирана шема
 запишаната вредност е долга 13 знаци
 25 пати изменет DES алгоритам се применува на блок со почетна
вредност сите нули и лозинката како клуч
 ги зема 7 најниски битови од првите 8 знаци како клуч за да се добие
56-битниот клуч на DES
 се користи 12-битна сол за да се сменат некои состојби во
алгоритамот, за DES да не биде реверзибилен
 резултантните 64 бита ги конвертира во 11 ASCII знаци со 6 бита за
знак (2 бита се падираат со нули), а пред нив се додаваат 2 знака за
солта
 пример, Dyq4bCxAXJkbg (сол||хеш_резултат)
Хеширање на лозинки во UNIX
BSDi проширена DES-базирана шема
 запишаната вредност е долга 20 знаци
 24-битна сол, променлив број на рунди (до 224-1) и подолги лозинки
 од подолгата лозинка се генерираат 8-те 7-битни врености за DES
клучот
 избраниот број на рунди е енкодиран во складираниот хеш на
лозинката
 овие хешови се познаваат по тоа што почнуваат со знакот “_” следен
со 4 бајти за бројот на рунди
 пример, _EQ0.jzhSVeUyoSqLupI (_рунди||сол||хеш_резултат)
Хеширање на лозинки во UNIX
MD5 -базирана шема
 нема граница за големината на лозинката и за солта
 не мора да се користат само знаци од ASCII
 најпрво лозинката и солта се хешираат заедно со MD5, а потоа се
конструира нов резултат од лозинката, солта и првиот хеш резултат
на сложен начин. Потоа ова минува низ 1000 итерации на
рехеширање со одредени разлики во рундите
 се индицира со $1$ на почетокот на хеш резултатот
 делот со хеш резултат е долг 22 знаци, ако солта е долга 48-бита, се
енкдира како 8 знака во записот
 пример, $1$etNnh7FA$OlM7eljE/B7F1J4XYNnk81
 ($идентификатор$сол$||хеш_резултат)
Хеширање на лозинки во UNIX
SHA2 -базирана шема
 се индицира со $5$ (SHA-256) и $6$ (SHA-512) на почетокот на
енкодираниот хеш резултатот
 само хеш резултатот се енкодира со 43 знаци за SHA-256 и 86 знаци за
SHA-512
 на пример,
$5$9ks3nNEqv31FX.F$gdEoLFsCRsn/WRN3wxUnzfeZLoooVlzeF4WjL
omTRFD или
 $5$rounds=5000$anexamplestringf$KIrctqsxo2wrPg5Ag/hs4jTi4Pmo
NKQUGWFXlVy9vu9
 $6$qoE2letU$wWPRl.PVczjzeMVgjiA8LLy2nOyZbf7Amj3qLIL978o18
gbMySdKZ7uepq9tmMQXxyTIrS12Pln.2Q/6Xscao0 или
 $6$rounds=5000$anexamplestringf$Oo0skOAdUFXkQxJpwzO05wgRH
G0dhuaPBaOU/oNbGpCEKlf/7oVM5wn6AN0w2vwUgA0O24oLzGQ
pp1XKI6LLQ0.
 ($идентификатор$rounds=број$сол$||хеш_резултат)
Привилегии на root
Скоро и да нема безбедносни проверки:
 сите механизми за контрола на пристап се исклучени
 може да стане обичен корисник
 може да го менува системскиот часовник
Има некои рестрикции, но можат да се надминат:
 не може да запишува во системските датотеки поставени само
за читање, но може системот повторно да го монтира во
систем за пишување
 не може да дешифрира лозинки, но може да ги ресетира
Секое корисничко име може да биде root!
root:x:0:1:root:/:/bin/sh
bilokoj:x:0:101:Nekoj korisnik:/home/bilokoj:/bin/sh

/bin/su – за промена во супер-корисник

Главен недостаток на UNIX!
Датотека за групи
Корисниците припаѓаат на една или повеќе групи
Секој корисник припаѓа на примарна група и
нејзиниот GID е зачуван во /etc/passwd
Во некои верзии на UNIX (UNIX System V) корисникот
може да припаѓа само во една група. Групата се
менува со newgrp. Во Berkeley Unix корисникот може
да биде во повеќе групи и нема потреба од newgrp
Датотеката /etc/group содржи листа на сите групи

Groupname: Password: GID: Members

Пример:
root:x:0:
infosecwww:x:209:dime, alf
Шелови
Интерфесјите за командна линија во Unix се
нарекуваат шелови (shells)
Korn Shell, Born Shell, C-shell,...
Со даден шел, корисникот внесува различни команди,
како листање на содржина на директориум, бришење
датотека, извршување програма и сл.
цело време шелот одржува тековен директориум, и
командите манипулираат со датотеките релативно во однос
на тековниот директориум.
Субјекти
Субјекти вo UNIX се процесите и тие се идентификуваат
со process ID (PID).
Секој процес има 3 UID (+ повеќе под Linux) и 3 GID
 Реален кориснички ID (Real user ID - RUID)

 Тоа е ID на процесот кој го креирал тековниот процес (ID на

родителскиот процес)
 На пример, ако сте логирани како Ana со UID=1000, вашиот
шел е стартуван со RUID поставен на 1000 и сите процеси кои
ги стартувате од вашиот шел ќе го наследат RUID 1000 како
нивни RUID.
 Го идентификува вистинскиот сопственик на процесот и влијае
на дозволите при испраќање на сигнали. Процес без superuser
привилегии може да му сигнализира на друг процес ако RUID
или EUID на испраќачот се совпаѓа со RUID или SUID на
примачот.
Субјекти
 Ефективен кориснички ID (Effective user ID - EUID)
 ID кое системот го користи за да утврди дали процесот може
да изврши одредена акција
 на пример, пристап до датотека и поврзување со порта
 Се користи и како сопственик за датотеките креирани со тој
процес
 Се наследува од родителскиот процес или од сопственикот на
процесот кој се извршува
 Има два познати начина како да се промени EUID:
 su – оваа програма ги менува сите три вида на ID со оние на корисникот
на кој се префрлате
 Set User ID битот – кога овој бит е поставен програмата се извршува со
EUID и SUID поставени на сопственикот на програмата, а RUID останува
непроменет. На пример, ако креирате програма со RUID 1000, и ако го
променете сопственикот со chown на root и го вклучите SETUID битот со
chmod +s, тогаш кога програмата ќе се извршува, нејзиниот RUID ќе биде
1000, a EUID и SUID ќе бидат 0.
Субјекти
 Снимен кориснички ID (Saved user ID - SUID)
 SUID се поставува на EUID кога процесот се стартува.
 Се користи кога процес со поголеми привилегии, мора
привремено да направи некоја непривилегирана работа, па со
SUID процесот може да го обнови оригиналниот EUID, откако
неговиот EUID ќе падне на непривилегиран ID
(непривилегиран процес може да го промени своето EUID само
на неговите RUID и SUID)
 Ова може да предизвика многу проблеми ако не се менаџира
правилно
Ако стартувате програма без поставен SETUID бит, таа ќе
се извршува со RUID, EUID и SUID поставени на вашиот
UID
Субјекти
Креирање на нов процес
 fork: креира нов процес дете кој е идентичен со родителскиот
процес , но со нов PID- ги наследува сите три ID од
родителскиот процес
 vfork: исто како fork само што меморијата е делена меѓу двата
процеса
 exec family: го заменува тековниот процес со слика на нов
процес. Притоа, ги задржува трите UID, освен ако SETUID битот
на датотеката е поставен, и тогаш EUID и SUID се поставуваат
на UID сопственикот на датотеката
Објекти
Датотеките, директориумите, мемориските уреди, В/И
уреди и други, униформно се третираат како ресурси
кои подложат на контрола на пристап.
Сите ресурси се организирани во податочен систем со
структура на дрво.
Секој ресурс во директориумот е покажувач на inode
податочна структура која ги опишува основните
особини на ресурсот.
Секој директориум содржи покажувач кон самиот себе,
т.е. датотеката “.” и покажувач кон својот матичен
директориум, т.е. датотеката “..”.
Секоја датотека има сопственик и припаѓа на група.
POSIX Inode структура
size –големина на датотеката во бајти
Device ID - идентификатор за уредот со датотеката
uid – идентификатор на корисник
gid - идентификатор на примарната група
mode – тип на датотека и права за контрола на
пристап
atime – последно време на пристап
mtime - последно време на промена на датотеката
itime - последно време на промена на inode
link count – број на хард линкови до inode
pointers – покажувачи до физички блокови со содржина
од датотеката
Хард линкови
Директориум е низа од парови (ime_datoteka, inode
adresa). Секој влез на директориумот се нарекува хард
линк до дадена датотека.
 корисникот може да креира повеќе хард линкови до иста
датотека и нивниот број е зачуван во link count
Кога корисникот брише датотека, всушност се брише
само еден хард линк до датотеката и link count се
намалува за еден. Кога link count ќе стане 0, се брише
целата датотека.
На овој начин повеќе корисници може да делат
заедничка датотека безбедно, без едниот да може да ја
избрише датотеката, додека другите се уште ја
користат.
Mode полето
Тип на датотека/ресурс
 ’-’ датотека setid
 ’d’ директориум
 ’b’ block device file - rwx rwx rwx
 ’c’ character device file ownr grp othr
 ’s’ сокет
 ’l’ симболичка врска
 ’p’ FIFO
Дозволи за контрола на пристап
 Read, write, execute (- значи правото не е дадено)
 Owner, group, other
 Се претставува со вектор од 4 октални вредности
Mode полето - пример
-rw-r--r-- 1 ana ana 10652 ... 08-unix.tex
lrwxrwxrwx 1 root root 15 ... stdin -> /proc/self/fd/0
crw------- 1 ana tty 136 ... /dev/pts/1
Уште за објекти во Unix
Кој може да ги менува дозволите за
контрола на пристап?
 Сопстевникот и root можат
Кој може да го промени сопственикот?
 Само root
Дозволи за директориуми
read: пребарување на директориумот, на пример со ls
write: промена на содржината на директориумот,
креирање и бришење на датотеки и директориуми
execute: правење на директориумот тековен и/или
отворање на датотеки во него. Може да отворите
датотека во директориумот ако знаете дека постои, но
не можете да го користете ls за да видите што им во
директориумот.
Раководење со дозволи
Октално енкодирање на дозволи
 read-only: 100  4
 read-write: 110  6
 read-write-execute: 111  7
Промена на дозволи
 chmod 777 filename
 chmod u+rwx,g+rx,o-w filename
Промена на сопственик на датотека (само root)
 chown user:group filename
Промена на група на датотека
 chown user:group filename
Раководење со дозволи
if user = owner then owner permission
else if user in group then group permission
else other permission

Сопственикот може да има помали привилегии

на пристап од останатите корисници!
Предефинирани дозволи
Предефинираните дозволи вообичаено се 666 при
креирање на нова датотека и 777 за директориуми.
umask наредбата ги менува предефинираните дозволи
 umask [mask]
 mask ги специфицира правата кои треба да се укинат
 инверзијата на mask е коњугирана (AND) со тековните дозволи
Примери:
Контролирано повикување
Некои акции како на пример, користење на
системските порти (1-1023) или промена на лозинка,
бараат привилегија на root.
На корисниците не треба да им се дадат привилегии на
root со кажување на лозинката на root, туку само право
да извршуваат одредени команди како root.
Решение: се поставува специјално знаменце кое
индицира дека програмата се извршува со привилегии
на нејзиниот сопственик, а не на корисникот кој ја
повикува.
Недостаток: ова право не може да се даде на одредени
корисници: сите корисници од група или од “други”
може да ја извршуваат програмата со привилегии на
нејзиниот сопственик.
SETUID, SETGID и лепливо
знаменце
Четврт октален број се додава на дозволите со
следните значења на битовите:
 SETUID: го поставува EUID на процесот на ID од сопственикот
на датотеката. Ова овозможува корисниците привремено да
бидат третирани како root или друг корисник
 SETGID: го поставува EGID на процесот на GID на датотеката.
Кога се применува на директориум, новокреираните датотеки и
директориуми во тој директориум ја наследуваат неговата
група.
 лепливо знаменце (sticky flag):
 Off: ако корисникот има дозвола за пишување во директориумот, може да
преименува, преместува и брише датотеки, дури и ако не е сопственик
 On: само сопственикот на директориумот и root може да ги преименуваат,
преместат или избришат датотеките од директориумот
SUID, SGID и лепливо знаменце
Се користи chmod со 4 октални цифри за поставување
на дополнителните знаменца:
 chmod 7644 08-unix.tex
 ls -l 08-unix.tex
 -rwSr-Sr-T 1 daskov daskov 13031 ... 08-unix.tex
Ранливости со монтирање на
податочен систем
Со монтирање на надворешен податотечен систем, не
може да се гарантира дека е слободен од злонамерни
програми, на пример SETUID програми.
Како резултат, контролата на пристап теба да се
редефинира за монтираните медиуми
Безбедносни опции за наредбата mount:
 -r: read-only монтирање
 -o nosuid: исклучи ги SET
 UID знаменцата за сите податоци во монтираниот податочен
систем
 -o noexec: не може да се извршува програма од монтираниот
податочен систем
 -o nodev: не може да се пристапува на уреди од монтираниот
податочен систем
Ранливости со патишта на
пребарување
Потенцијална опасност лежи во можноста напаѓачот да
започне со извршување на погрешна програма со исто
име.
Правила:
 Ако е можно, да се специфицира целосниот пат на повиканите
програми, на пример /bin/sh наместо sh.
 Истото да се применува за програмите кои се извршуваат
локално: користете ./program наместо program.
 Бидете сигурни дека . е првиот симбол во променливата PATH.
Ова барем ќе спречи да се повика “remote” верзија на
програмата ако сакате “local” повикување.
Ранливости со уреди како
датотеки
Уредите се преставени како датотеки
 /dev/tty – терминал
 /dev/mem – физичка меморија
 /dev/kmem – виртуелна меморија
 /dev/mouse – глушец
Се креираат со mknod (само root има пристап)
Може да ја заобиколат контролата на пристап со
пристап до меморијата
 /dev/kmem или /dev/mem се пристапливи од Other
Може да имаат пристап до корисничкиот влез
 /dev/tty се чита од Other– гледа лозинки и клучеви
Ранливости со симболички
линкови
Симболички линк (symbolic link, symlink или soft link) е
име за било која датотека која содржи референца до
друга датотека или директориум во форма на
апсолутен или релативен пат.
Тие не користат link count, па може да покажуваат на
непостоечка датотека или на датотека креирана
покасно. Ако програмата пристапува на датотека преку
симболички линк, тогаш напаѓач може да замени друга
датотека со името на датотеката на која покажува
симболичкиот линк, и ова ќе предизвика програмата да
чита или запишува од датотеката на напаѓачот.
Syslog и CRON
Syslog алатката им дозволува на систем
администраторите да прават логови од
различни настани во еден Unix систем.
Cron e Unix распоредувач на работи
Многу систем администратори го користат
Cron за изведување на автоматски задачи
во системите.
Cron може да се користи и за испраќање
на лог датотеки по електронска пошта, и
др.
Безбедносни карактеристики кои
недостасуваат во Unix
ACLs во општ случај
Нивоа на безбедност и класифицирање на податоци,
на пример secret, classified и др.
Задолжителна контрола на пристап, па корисниците да
не можат да заобиколат одредени безбедносни одлуки
донесени од администраторот (на пример chmod 777
$HOME е секогаш можно)
Можностите (Capabilities) се подржани само од мало
подмножество на оперативни системи од фамилијата
на UNIX (на пример Linux со верзии на јадрото над
2.4.19)
Стандардизирано следење.
Резиме
Unix обезбедува множество на флексибилни
безбедносни механизми; сепак, нивната ефикасност се
базира на внимателна администрација со знаење.
Unix не обезбедува неколку клучни функции
предложени од моделите на безбедност како на
пример, нема ACLs или нивоа на безбедност.
Главната безбедносна сила лежи во имплементацијата
со отворен код; оттука, безбедносните грешки рано се
откриваат и поправаат.