From: Volkan KUMBASAR (kumbi2000@yahoo.de)
Date: Sat 23 Dec 2000 - 20:09:18 EET
ben o linki bulamdigim
bu konuda bana yardimci olrsan sevinirim
On Sat, 23 Dec 2000, you wrote:
> nsa.gov yeni bir linux distribi cikarmis selinux(Secure Linux) yeni system_calleri yazmislar.Bilemiyorum ne kadar secure (indirecek+kullanacak zamanin olmadi) ama belki listeye atarsam iyi olur diye dusundum.Linux icin cikarilan rsbac (rule set acces control list) patchi ile ayni amaclari tasiyorlarmis.(www.rsbac.org)Eh hadi hayirlisi
> Ilgilenenler icin www.nsa.gov/selinux
>
>
> --------------------
> The Security-Enhanced Linux has a well-defined architecture for
> flexible mandatory access controls that has been experimentally
> validated through several prototype systems (DTMach, DTOS, and Flask).
> The architecture provides clean separation of policy from enforcement,
> well-defined policy decision interfaces, flexibility in labeling
> and access decisions, support for policy changes, and fine-grained
> controls over the kernel abstractions. Detailed studies have been
> performed of the ability of the architecture to support a wide variety of
> security policies and are available on the DTOS and Flask web pages
> accessible via the Background page.
>
> The security architecture is described in the overview
> section of the kernel document (Integrating Flexible Support
> for Security Policies into the Linux Operating System). On
> the Background page, you will also find a copy of a published paper
> about the security architecture (The Flask Security Architecture:
> System Support for Diverse Security Policies).
>
> RSBAC appears to have similar goals to the Security-Enhanced Linux.
> Like the Security-Enhanced Linux, it separates policy from enforcement
> and supports a variety of security policies. RSBAC uses a different
> architecture (the GFAC) than the Security-Enhanced Linux, although the
> Flask paper notes that at the highest level of abstraction, the
> the Flask architecture is consistent with the GFAC. However,
> the GFAC does not seem to fully address the issue of policy changes
> and revocation, as discussed in the Flask paper. RSBAC also differs
> in the specifics of its policy interfaces and its controls, but
> a careful evaluation of the significance of these differences has
> not been performed.
>
> Unlike traditional trusted operating systems, the Security-Enhanced
> Linux provides flexible support for security policies. It can
> support multi-level security, but it can also support Type
> Enforcement, Role-Based Access Control, and other kinds of
> policies. Furthermore, since it cleanly separates policy
> from enforcement, the security policy logic can be radically
> revised without requiring any changes to the rest of the
> operating system.
>
>
> The POSIX.1e capabilities allow one to decompose superuser
> privileges. This is not the same as a mandatory access control
> mechanism, and it does not support enforcing the separation of
> information
> based on integrity and confidentiality requirements.
> In the Security-Enhanced Linux, these capabilities do not
> override the mandatory access controls. In fact, the ability
> to use a capability is controlled by the mandatory access controls.
> Since the Security-Enhanced Linux provides subject labeling,
> it can restrict the use of capabilities to the appropriate programs
> through the centralized security policy configuration.
>
> In one of the predecessors of the Flask architecture (the DTOS system),
> the NSA implemented a more general mechanism for decomposing superuser
> privileges. The superuser privileges were partitioned by having the
> security server return a set of override decisions along with its
> access decisions, where these override decisions could cause access
> to be granted even if the Unix access control would ordinarily deny
> access. Unlike the Linux capabilities, these override decisions could be
> based on both the label of the subject and the label of the relevant
> object. This mechanism permitted fine-grained decomposition (e.g.
> permission to override DAC read restrictions could be limited to files
> with certain security labels) and simpler management (through the use of
> the centralized security server). Similar support could be added to the
> Security-Enhanced Linux as well but is not present in the
> current implementation.
>
> --
> Stephen D. Smalley, NAI Labs
> sds@tislabs.com
>
> ==
> Omer Faruk Sen
> www.faruk.net
> Yildiz Technical University
> Electronic & Communication Eng.
>
> _____________________________________________________________
> Get email for your site ---> http://www.everyone.net
>
>
> Listeden cikmak icin:
> unsub linux
> mesajini listeci@bilkent.edu.tr adresine gonderiniz.
> Lutfen Listeci icin MIME / HTML / Turkce Aksan kullanmayin.
> Listeci arayuzu: http://listweb.bilkent.edu.tr/yardim/bilkent/linux.html
> Liste arsivinin adresi: http://listweb.bilkent.edu.tr/
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de
Listeden cikmak icin:
unsub linux
mesajini listeci@bilkent.edu.tr adresine gonderiniz.
Lutfen Listeci icin MIME / HTML / Turkce Aksan kullanmayin.
Listeci arayuzu: http://listweb.bilkent.edu.tr/yardim/bilkent/linux.html
Liste arsivinin adresi: http://listweb.bilkent.edu.tr/