AToL: SELinux architecture and kernel remarks

5.8.2012 12:58 | Přečteno: 1039× | Linux | poslední úprava: 5.8.2012 12:58

Autor: Ondřej Kozina
Nasledovný príspevok je študentskou prácou, ktorá vznikla v rámci predmetu Advanced Topics of Linux Administration. Predmet je vypisovaný na Fakulte informatiky MU v spolupráci so spoločnosťou Red Hat Czech. Vyučovacím jazykom je angličtina a preto je v nej aj nasledovný príspevok, študent nemá právo výberu iného jazyka. Komentáre k obsahu príspevku sú vítané v ľubovoľnom zrozumiteľnom jazyku.

SELinux architecture and kernel remarks

For quiet a long time POSIX systems have got along with so called discretionary access control (DAC). It means that system trusts its applications they work as intended. If e.g. ls has the privilege to read the content of some directory, it is OK to let it read. But if someone attacker changed ls binary in a way the new application will read sensitive data and send it silently to attacker's server. The answer is to confine the application by fence of minimal access privileges they need to serve their purpose. Obviously ls has no reason to open socket connections on network layer (in any way). This principal is called mandatory access control (MAC).

SELinux is just one among many implementations of LSM (Linux Security Model) kernel framework, that brings complex MAC to Linux. The other members of LSM family are Tomoyo, AppArmor, Yama or Smack. Moreover SELinux implements FLASK (Flux Advanced Security Kernel) architecture which is more general concept describing model for flexible and dynamic type of enforcement mechanisms. FLASK architecture has its roots in 1980s and one of research projects that gave life to FLASK was designed for microkernel based operating systems. The microkernel design is well reflected even in SELinux architecture itself.

SELinux architecture

Kernel space part

SELinux components spans over kernel space as well as user space. The kernel part consists of three strictly separated components where each one of them is responsible for its own part of a work and should be easily replaceable. This is sort of leftover from microkernel FLASK design. The core component is SELinux security server. This part is responsible for policy decisions. The second component, the AVC (access vector cache) is, and being obvious, cache that quickly responds previously returned policy decisions by security server during cache miss. The final part is a bundle of kernel object managers, that ensures type enforcement itself. Kernel object managers guarantee that any access request to its resources are properly translated into access vector queries to security server. So usual workflow looks like: You want to access inode? It's a kernel object, so kernel object manager has to query AVC for an answer. If AVC miss then it'll ask security server for an access vector decision. This decision is then stored into AVC.

User space part

For the purpose this artcle, it's enough to state that user space part of SELinux is libselinux library. What is more important: user space part of SELinux (among other things) provides interface that helps to create user space object managers. These managers are used to maintain user space objects. OK, but what are the user space objects at all? Kernel space objects are clear: inodes, files, devices, sockets etc. But why should one bother to maintain some user space objects? Consider database management system. You want to limit users to use only certain resources of dbms. You can define various objects e.g.: tables, views, triggers, db links, etc. Then, you are able to label these objects accordingly to confine db users into more clearly defined area. Libselinux has its own AVC that caches decisions for user space managed objects. But the policy decisions and SELinux types/domains are still managed by security server!

Kernel type enforcement, how does it work?

Let's look at simple example of how the type enforcement works in kernel. What will happen when process requests opening some file (access inode)? Quick search through Linux sources reveals that apart from security functions there's only one place where an inode permissions are checked. It's the fs/namei.c source file.

int __inode_permission(struct inode *inode, int mask)
{
        int retval;

        if (unlikely(mask & MAY_WRITE)) {
                /*
                 * Nobody gets write access to an immutable file.
                 */
                if (IS_IMMUTABLE(inode))
                        return -EACCES;
        }

        /* DAC access control */
        retval = do_inode_permission(inode, mask);
        if (retval)
                return retval;

        /* cgroup checks for devices only */
        retval = devcgroup_inode_permission(inode, mask);
        if (retval)
                return retval;

        /* LSM security checks */
        return security_inode_permission(inode, mask);
}

As you can see, the process of deciding whether the user has access permissions for inode or has not actually proceeds in three steps. First the classical DAC rights are checked, then cgroups (Control Groups) permissions. Cgroup permissions check takes effect only on inodes regarding block or character devices. The final check is the LSM check itself. In general that means you have to pass all three security checks to gain the access.

Access revocation, Does SELinux help?

Access revocation is unending story about how to revoke access to resources after the permission settings are changed in a sane way. Process 'A' has access permission to some file 'F'. The process has opened the file and now it can write the file through open fd. But even if you change the access rights to the file's inode you won't interrupt the process 'A' from writing the file through open fd. Only each future call to open syscall will fail. What SELinux offers is actually 'sort of' revocation by changing the object's type. In our case you can change inode's type and during the next write syscall, SELinux will fail the write call. It shouldn't be expensive as after first query the AVC will store the access decision and every following write call will receive the answer from AVC. Actually, SELinux hook function can detect if security context of inode has changed since the file has been opened. LSM support this feature by security_file_permission hook and it's up to security module if it implements it or not. Did you know that?:)

Fun with ioctl permission

If you glimpse shortly into linux/security.h header file you'll find out there are hook functions for most of the system calls. But especially one syscall, the ioctl is a bit different. Ioctl syscall represents kernel configuration interface used to interchange data between user space and kernel space. In the beginning it's been used as configuration interface for tty devices solely, but later it's become general configuration interface. Nowadays, there are dozens of different ioctl calls in the kernel. List of devices that are configured by ioctl syscall is quite a long one: all *-ROM mechanics, SCSI devices, device-mapper virtual devices, loop devices, etc. What is a real challenge with the ioctl syscall is the fact, that ioctl is actually a syscall to implement new syscall within the kernel. Why so? The ioctl syscall prototype is:

int ioctl(int fd, unsigned long commmand, ...);

commmand parameter is an ioctl identifier number. The id contains information about command type and its direction (write data to kernel, read data into user space). The third variable parameter can be of any type or null. There are two major arguments why security people don't like the ioctl syscall. The first reason is, that ioctl handler (usually a device driver) has to be very careful about the third parameter passed from user space. The user memory has to be copied into kernel memory space and you need to check if every string is correctly terminated. Fail to do and you risk that user try to do some ugly things with the memory beyond the unterminated string. The second argument is simple. If you consider the abundant quantity of different ioctl implementations you will simply realise that its nearly impossible to verify every ioctl. The security maintainer would have to check every ioctl implementation and also he would have to completely understand what is driver trying to do during the ioctl handling. For example: you can have driver that receives read only ioctl parameter. That means the driver will fill user provided area with some data from kernel. It's supposed to supply some statistic data about device usage. But the driver author may have decided to do some potentially harmful operation during ioctl handling (for example reset the statistic data to initial value). Do you want that operation to be accessed by general user? Or rather, do you want only some privileged user to do that operation. And who should decide that? In any way, this decision should not be made be SELinux maintainers but by the person responsible for the device driver. And I don't even mention that some drivers are at least partially rewritten from time to time. So if you look into SELinux implementation of security_file_ioctl hook you'll find out that there are only a few ioctl commands that SELinux cares about:

static int selinux_file_ioctl(struct file *file, unsigned int cmd,
                              unsigned long arg) {
        /* ... */
        switch (cmd) {
        case FIONREAD:
                /* fall through */
        case FIBMAP:
                /* fall through */
        case FIGETBSZ:
                /* fall through */
        case FS_IOC_GETFLAGS:
                /* fall through */
        case FS_IOC_GETVERSION:
                error = file_has_perm(cred, file, FILE__GETATTR);
                break;

        case FS_IOC_SETFLAGS:
                /* fall through */
        case FS_IOC_SETVERSION:
                error = file_has_perm(cred, file, FILE__SETATTR);
                break;

                /* sys_ioctl() checks */
        case FIONBIO:
                /* fall through */
        case FIOASYNC:
                error = file_has_perm(cred, file, 0);
                break;
        case KDSKBENT:
        case KDSKBSENT:
                error = cred_has_capability(cred, CAP_SYS_TTY_CONFIG,
                                SECURITY_CAP_AUDIT);
                break;

                /* default case assumes that the command will go
                 * to the file's ioctl() function.
                 */
        default:
                error = file_has_perm(cred, file, FILE__IOCTL);
        }       
        return error;
}

As you can see only a few ioctl commands are somehow translated into more specific SELinux permission checks like FILE__GETATTR or FILE__SETATTR. The default behaviour is to check only general FILE__IOCTL permission or in other words: SELinux verifies if current process is in proper domain to do ioctl on open file. The short answer on question why SELinux doesn't care about the specific ioctl commands is that only the driver's author (should :)) knows about the driver's internals.

I hope you find at least some parts of the blog entry interesting and feel free to discuss any misleading info or clear mistakes. Thanks you for reading

       

Komentáře

[smazáno]

Promin, ale napsat to musim - opravdu by to chtelo jeste trochu zamakat na anglictine, ono mozna mas napady dobry ale z toho textu se dost tezko ctou. Na druhou stranu az budu umet tak dobre spanelsky jak ty anglicky tak budu happy

(to je teda prvni prispevek )

[marek]

Po podrobném přečtení mám pocit, že autor blogu si pouze myslí, že ho napsal anglicky.

[pavlix]

Angličtina jako světový dorozumívací jazyk často nedosahuje kvalit angičtiny jako národního jazyka, ať už britského, amerického či australského. Já osobně jsem se s tím schopný v pohodě smířit, v případě podobných textů hodnotím radši obsah.

V případě beletrie to mám zase trochu jinak, ale tam musím říct, že je jenom pár autorů, kteří mě stihli jazykově zaujmout. Z těch novodobých je to Umberto Eco (kupodivu neangličan neameričan) a J.R.R. Tolkien. Jestli máte někoho kvalitativně srovnatelného v zásobě, tak si rád přečtu.

[David Jaša]

Jestli máte někoho kvalitativně srovnatelného v zásobě, tak si rád přečtu.

James Joyce. Četl jsem od něj jen sbírku povídek Dubliners, ale stála za to.

[pavlix]

Díky, počítám, že si do roka a do dne od něj něco přečtu. Bohužel už nečtu tak intenzivně, jako dosud, a na seznamu mám těch věcí trochu více. Sbírka povídek se zdá býti ideální.

[luv]

Od Joyce(e) jsem zkusil precist "A Portrait of the Young Artist" ale po padesati strankach jsem to zahodil .

Ale z klasiku, kteri se vyzivaji v hrani s jazykem (a narozdil od JJ se to da cist), je skvely Charles Dickens

[pavlix]

Dávám na seznam za Joyce.

[David Jaša]

Dubliners se dali číst velmi dobře - jejich čitelnost je v příkrém rozporu s Joycovou pověstí.

[pavlix]

Ahoj. Mám pro tebe takovou menší poznámky k textům tohoto typu. I když máš pocit, že text je „pouze“ o architektuře, tak bys tam měl mít alespoň jednu sekci o tom, k čemu je to vůbec dobré.

Případ SELinuxu je navíc zajímavý tím, že se SELinux používá, a to už pár let. Takže by stálo za to v takové sekci (či v samostatné, to už je volba autora), uvést i na co se SELinux reálně používá a na co se třeba reálně nepoužívá.

Příklad s ls je dobrý v tom, že je jednoduchý a jasný. Na druhou stranu je to ale utilita a spouští se obvykle z shellu nebo jiné čistě uživatelské aplikace. Tudíž běží obvykle s právy uživatele a navíc alespoň ve Fedoře nemá nastavený žádný speciální typ.

$ ls -Z /bin/ls
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /bin/ls

Takže z praktického hlediska postrádá smysl a lepší by bylo jako příklad použít něco, co se opravdu SELinuxem už dneska v praxi zabezpečuje nebo to alespoň dává nějaký konkrétní smysl.

Snad to pomůže.

[Jendа]

Jak je na tom SELinux s Xkama? Taková ta věc, jak nikdy nevím, jak se jmenuje, má jakýsi bezpečnější kreslící protokol.

[Nicky726]

Existuje nástroj sandbox, který má verzi pro GUI aplikace, myslím, že sandboxx?

[Jendа]

Hmm, tohle používá Xephyr, zkoušel jsem něco podobného s Xnest a výkon vykreslování nebyl nic moc (čti Firefox v tom byl nepoužitelný). Navíc samozřejmě nefunguje třeba xclipboard.

[Jendа]

Jů, tak Xephyr umí RandR extension, clipboard se dá ohackovat a tak… Nejvyšší čas přesunout půlku systému do virtualizace nebo rozchodit SELinux/grsec/Tomoyo :).

[David Jaša]

Proč nebo?

[Bystroushaak]

Když už jsme u Selinuxu - potřeboval bych si zabezpečit server, ale z letmého pohledu na Selinux mám pocit, že tohle není zrovna věc, při které bych si zachoval duševní zdraví (zábavné jsou 50 stránkové tutoriály, dočtení něčeho takového bych se nemusel dožít..). Existuje na to nějaké klikátko, nebo něco jednoduššího?

[Marek 'marx' Grác]

V podstate toho až toľko nepotrebuješ, na štandardné serverové aplikácie ti stačí 'targeted policy' a k tomu si pozrieť, čo všetko sa tam dá nastaviť (setsebool). Na písanie pravidiel pre vlastný softvér je možné si prejsť logy a pridať do to pravidiel, obvykle to funguje podľa predstáv.

[pavlix]

Standardně se selinux řeší tak, že software/OS dostaneš i s bezpečnostní politikou a maximálně si doladíš pár nastavení pomocí setsebool. Psaní bezpečnostních politik se v tomto případě nepovažuje za běžný administrátorský úkon.

[Bystroushaak]

Nj, jenže já chci zabezpečit vlastní SW. Jinak jsem googlil, až jsem narazil na apparmor, který vypadá docela jednoduše.

[David Jaša]

Protlač ho do Fedory a dostaneš selinuxí politiku zadarmo.

[David Jaša]

Ještě takový dodatek: pokud si tu bezpečnostní politiku bastlíš pro tvůj vlastní soft běžící na tvém vlastním serveru, můžeš si vybrat. Ale pokud ten tvůj soft pojede u někoho cizího, bude mít při výběru bezpečnostního frameworku hlavní slovo jeho správce serverů.

[Bystroushaak]

Jo, to je jasné. Jede to u mě na serveru, stahuje to nějaké ty data z netu, parsuje a ukládá. Jen taková paranoidní jistota kombinovaná s tím, že praxí se člověk nejlépe učí.

Jinak taky budu potřebovat omezit FTP pro jednoho kolegu, ale to zatím nespěchá (FTP pojede, až dodá disk) a předpokládám že konfigurák někde najdu.

[David Jaša]

Jinak taky budu potřebovat omezit FTP pro jednoho kolegu, ale to zatím nespěchá (FTP pojede, až dodá disk) a předpokládám že konfigurák někde najdu.

Kdybys na to chtěl přeci jen zkusit selinux, tak se obejdeš bez vlastních politik, stačí ti to jenom nastavit podle ftpd_selinux (8) (a na fedoře ještě předtím doinstalovat policycoreutils-python, v kterých je semanage).

[Bystroushaak]

Nj, ale apparmor tam už byl, selinux ne :) Jinak selinux mám na desktopu, mint ho má v sobě tak pěkně nacpanej, že se nedá úplně odinstalovat, protože na něm závisí skoro všechno :D Takže na desktopu apparmor nebude, což me donutí se na selinux někdy podívat.