Chemnitz, Techn. Univ., Studienarb., 2006.

<p>This thesis makes a comparative study of the security systemsSystrace (used primarily with OpenBSD) and SELinux (usedexclusively with Linux), trying to answer the question as to whichtype of security is offered by each respective system, and wheneach should be used. The key difference between SELinux andSystrace seems to be their mode of operation, where SELinux,built around the LSM framework in the Linux kernel, works withtype enforcement on files, sockets and other objects, whereasSystrace works on a strict system call basis. The two systems areseen to serve two different purposes which sometimes overlap,but in just as many cases provide solutions for entirely differentquality priorities.</p>

SELinux ist eine Erweiterung für das Betriebssystem Linux, deren Einsatz eine Erhöhung der Systemsicherheit verspricht. Dieses Tutorial stellt einige der Grundlagen und Mechanismen von SELinux vor. Es gibt einen Einblick in Nutzung und Konfiguration. / SELinux is an extension to the Linux operating system. It promises an increase in system security. This tutorial introduces some of the principles and mechanisms of SELinux. It provides insight into its usage and configuration.

This thesis makes a comparative study of the security systemsSystrace (used primarily with OpenBSD) and SELinux (usedexclusively with Linux), trying to answer the question as to whichtype of security is offered by each respective system, and wheneach should be used. The key difference between SELinux andSystrace seems to be their mode of operation, where SELinux,built around the LSM framework in the Linux kernel, works withtype enforcement on files, sockets and other objects, whereasSystrace works on a strict system call basis. The two systems areseen to serve two different purposes which sometimes overlap,but in just as many cases provide solutions for entirely differentquality priorities.

No description available.

Táto diplomová práca sa zameriava zvyšovanie bezpečnosti v operačných systémoch založených na Red Hat Enterprise Linux, na základe analyzovaných zraniteľnosti za posledných 5 rokov. V teoretickej časti sú popísané slabiny a zraniteľnosti, základné bezpečnostné mechanizmy v Linuxe, so zameraním na technológiu SELinux. Technológia SELinux je súčasťou operačných systémov Red Hat Enterprise Linux, Fedora a CentOS. Na základe analyzovaných zraniteľností bola v praktickej časti navrhnutá konfigurácia technológie SELinux. V návrhu sú popísané prvky, ktoré sa budú konfigurovať a tými sú SELinuxové booleany, SELinuxové moduly a SELinuxoví užívatelia, so zameraním na ochranu pamäte, eskalovanie privilégií, spúšťaniu kódu, úniku dat a obmedzenie procesov a užívateľov. Na základe návrhov bola vytvorená konfigurácia v konfiguračnom nástroji Ansible, ktorej cieľom je umožniť užívateľovi jednoducho a rýchlo nakonfigurovať hosťa. Okrem nej boli vytvorene ďalšie dve konfigurácie, ktoré umožnia vrátiť systém do predchádzajúceho stavu alebo uzamknúť SELinuxovú konfiguráciu. Následne sa overoval dopad konfigurácií na použiteľnosť systému a nájdené chyby boli opravené alebo nahlásené. Posledná časť overuje funkčnosť konfigurácie pred zneužitím zraniteľností.

La présente thèse s'intéresse à coder la politique de sécurité SELinux en OrBAC et à proposer une extension de ce modèle. Nous avons commencé par présenter l'état de l'art des différents modèles de contrôles d'accès présents dans la littérature en mettant en exergue les limites de chacun de ces modèles. Ensuite nous avons présenté le modèle OrBAC comme étant une extension du modèle RBAC, car d'une part il a apporté la notion de contexte et d'organisation et d'autre part il permet d'exprimer, en plus des permissions, des interdictions et des obligations. Ensuite, nous avons présenté la solution de sécurité SELinux qui utilise un ensemble de modèles de contrôle d'accès comme DAC, RBAC et MAC. Nous avons recensé plusieurs centaines, voire des milliers, de règles dans la politique de sécurité SELinux, ces règles peuvent concerner des décisions d'accès ou des décisions de transition. Nous avons ensuite pu coder lesdites règles en modèle OrBAC, et ce en passant par le remplissage ses tables d'entité, pour ensuite les transformer en relations OrBAC. Notre thèse a aussi rappelé les fondements de la logique possibiliste, et a ensuite apportée une amélioration importante du modèle OrBAC, il s'agit de l'introduction de l'entité priorité au niveau de chaque relation du modèle OrBAC. L'entité priorité quantifie la certitude pour qu'une entité concrète soit injectée dans l'entité abstraite correspondante, ou en cas général, le degré de certitude pour qu'une relation soit réalisée. Nous avons proposé trois modes de combinaison (pessimiste, optimiste et avancé) qui peuvent être adoptés pour déterminer la valeur de la priorité de chaque relation concrète à partir des priorités des relations abstraites correspondantes. Enfin, nous avons implémenté, via une application développé par DELPHI, le codage des règles concernant les décisions d'accès de la politique de sécurité SELinux, en modèle OrBAC tout en introduisant la notion de priorité. / This thesis focuses on encoding default-based SELinux security policy in OrBAC and propose an extension of this model. We presented the state of the art of different models of access controls present in the literature underlining the limitations of each of these models. Then we presented the model OrBAC as an extension of the RBAC model, firstly because he brought the notion of context and organization and secondly it allows expressing, in addition to permissions, prohibitions and obligation. Then we presented the SELinux security solution that uses a set of access control models such as DAC, RBAC and MAC. We identified several hundreds or even thousands of rules in SELinux security policy, these rules may be access decisions or decisions of transition. We could then encode these rules in OrBAC model, and via filling its tables of entities, then transform relations OrBAC. Our thesis also reviewed the foundations of possibilistic logic, and then made an important enlargement in OrBAC model; it's to introduce an entity called "priority" in each relationship model OrBAC. The entity "priority" quantifies the certainty for concrete entity injection into the corresponding abstract entity, in general, it's meaning the degree of certainty that a relationship is performed. We proposed three modes of combination (pessimistic, optimistic and advanced) that can be adopted to determine the concrete relations priority value from priorities values of each corresponding abstract relationship. Finally, we implement, via an application developed by DELPHI, coding access decisions rules of the SELinux policy in OrBAC model introducing the priority entity.

<p>To minimize the damage in the event of a security breach it is desirable to limit the privileges of remotely available services to the bare minimum and to isolate the individual services from the rest of the operating system. To achieve this there is a number of different containment strategies and process privilege security models that may be used. Two of these mechanisms are Solaris Containers (a.k.a. Solaris Zones) and Type Enforcement, as implemented in the Fedora distribution of Security Enhanced Linux (SELinux). This thesis compares how these technologies can be used to isolate a single service in the operating system.</p><p>As these two technologies differ significantly we have examined how the isolation effect can be achieved in two separate experiments. In the Solaris experiments we show how the footprint of the installed zone can be reduced and how to minimize the runtime overhead associated with the zone. To demonstrate SELinux we create a deliberately flawed network daemon and show how this can be isolated by writing a SELinux policy.</p><p>We demonstrate how both technologies can be used to achieve isolation for a single service. Differences between the two technologies become apparent when trying to run multiple instances of the same service where the SELinux implementation suffers from lack of namespace isolation. When using zones the administration work is the same regardless of the services running in the zone whereas SELinux requires a separate policy for each service. If a policy is not available from the operating system vendor the administrator needs to be familiar with the SELinux policy framework and create the policy from scratch. The overhead of the technologies is small and is not a critical factor for the scalability of a system using them.</p>

To minimize the damage in the event of a security breach it is desirable to limit the privileges of remotely available services to the bare minimum and to isolate the individual services from the rest of the operating system. To achieve this there is a number of different containment strategies and process privilege security models that may be used. Two of these mechanisms are Solaris Containers (a.k.a. Solaris Zones) and Type Enforcement, as implemented in the Fedora distribution of Security Enhanced Linux (SELinux). This thesis compares how these technologies can be used to isolate a single service in the operating system. As these two technologies differ significantly we have examined how the isolation effect can be achieved in two separate experiments. In the Solaris experiments we show how the footprint of the installed zone can be reduced and how to minimize the runtime overhead associated with the zone. To demonstrate SELinux we create a deliberately flawed network daemon and show how this can be isolated by writing a SELinux policy. We demonstrate how both technologies can be used to achieve isolation for a single service. Differences between the two technologies become apparent when trying to run multiple instances of the same service where the SELinux implementation suffers from lack of namespace isolation. When using zones the administration work is the same regardless of the services running in the zone whereas SELinux requires a separate policy for each service. If a policy is not available from the operating system vendor the administrator needs to be familiar with the SELinux policy framework and create the policy from scratch. The overhead of the technologies is small and is not a critical factor for the scalability of a system using them.

Tato práce se zabývá analýzou politik pro bezpečnostní moduly založené na mandatorním řízení přístupu (MAC), se zaměřením na SELinux. Vzhledem k omezeným schopnostem dostupných nástrojů byl navržen a implementován nový nástroj. Jeho hlavní cíle jsou usnadnění vývoje bezpečnostních politik a pomoc při odhadu role SELinuxu v zabezpečení systému. V případě úspěšného nasazení bude nový nástroj začleněn do balíčku nástrojů SETools 4.