SecurityEnhanced BSD

ChrisVance,RobertWatsonNetwork AssociatesLaboratories

�

15204OmegaDrive,Suit300Rockville,MD 20850

cvance@nai.com,rwatson@nai.com

July9, 2003

�

Thiswork wassupportedin partby DARPA/SPAWAR contractN66001-01-C-8035.

Contents

1 Intr oduction 4

2 Background 42.1 TrustedBSDMandatory Access ControlFramework . . . . . . . . 42.2 Linux SecurityModulesFramework . . . . . . . . . . . . . . . . 62.3 Framework Comparison . . . . . . . . . . . . . . . . . . . . . . 7

3 SELinux 103.1 Flask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Modified Programs . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 SEBSD 124.1 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 PortingFlask . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 SEBSDModule Initialization . . . . . . . . . . . . . . . . . . . . 134.4 UserInterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4.1 SystemControls . . . . . . . . . . . . . . . . . . . . . . 154.4.2 SystemCalls . . . . . . . . . . . . . . . . . . . . . . . . 16

4.5 LabelManagementTools . . . . . . . . . . . . . . . . . . . . . . 164.6 SEBSDUserSpaceApplications . . . . . . . . . . . . . . . . . . 17

5 SEBSDLabel Management 175.1 SEBSDLabels . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.1 ProcessLabels . . . . . . . . . . . . . . . . . . . . . . . 185.1.2 Mount Labels . . . . . . . . . . . . . . . . . . . . . . . . 185.1.3 File andPipeLabels . . . . . . . . . . . . . . . . . . . . 195.1.4 File HandleLabels . . . . . . . . . . . . . . . . . . . . . 195.1.5 Network andSystemV IPC Labels . . . . . . . . . . . . 20

5.2 LabelLife-cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3 Internalize/Externalize Operations . . . . . . . . . . . . . . . . . 225.4 Persistent File Labels . . . . . . . . . . . . . . . . . . . . . . . . 22

6 SEBSDEntry Point Implementation 236.1 ProcessEntry Points . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Mount Entry Points . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 File Entry Points . . . . . . . . . . . . . . . . . . . . . . . . . . 246.4 PipeEntry Points . . . . . . . . . . . . . . . . . . . . . . . . . . 276.5 File HandleEntry Points . . . . . . . . . . . . . . . . . . . . . . 276.6 SystemV IPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2

6.7 Network Support . . . . . . . . . . . . . . . . . . . . . . . . . . 286.8 Miscellaneous ModuleandSystemEntry Points . . . . . . . . . . 286.9 Entry PointComparison . . . . . . . . . . . . . . . . . . . . . . 29

7 Futur eDevelopment 29

8 RecentLinux Changes 30

9 Getting the Software 31

3

1 Intr oduction

Network AssociatesLaboratorieshascompletedaninitial portof theFlasksecurityarchitecture[1] andother componentsof Security EnhancedLinux (SELinux)[2] tothe FreeBSD[3]operating system. This project, called Security Enhanced BSD(SEBSD), startedwith theTrustedBSDMAC framework andintegratedtheFlaskaccessvector cacheandsecurity server to make policy decisions. Then,supportwasadded to thekernel to managesecurity fieldsandenforce permissionson filesandprocesses.

To demonstrate the resulting kernel functionality, a policy compiler andfile sys-temlabel managementtoolswereported. Also, modificationsto login, ls, andtheps program wereintegratedinto the corresponding FreeBSDprograms. This pa-perdiscussestheTrustedBSDMAC framework, labelmanagement,accesscontrolchecks,anddifferencesbetween SEBSD andSELinux.

2 Background

The introduction of new access control security features into operating systemsis an expensive process,both from the perspective of development,and in termsof long-term maintenance. A variety of approaches for security extension exist,but all have substantial problems, ranging from specific concernsover technicalcorrectness to high maintenancecosts. Many operatingsystemsecurity extensionsrely on modifications to the kernel to operate,preventing mandatory protectionsfrom being bypassed. However, this is oftendoneat theexpenseof flexibility . Forthese reasons,boththeLinux andFreeBSDopensourceoperatingsystemprojectsbeganthe developmentof generic, extensible security frameworks to help reducetheselong-termcostsandto helpfosterresearchinto better operating systemaccesscontrols.

2.1 TrustedBSD Mandatory AccessControl Framework

Network AssociatesLaboratories andthe TrustedBSD Projecthave implementedan extensible and modular kernel access control framework permitting new ac-cesscontrol policiesto be introducedinto the FreeBSDkernel[4, 5, 6, 7, 8]. TheTrustedBSDMandatory AccessControl(MAC) Framework addressesmany of thechallenges associated with introducing new access control services in operating

4

system kernels by abstracting commoninfrastructure servicesfrom the policies,reducing the cost and complexity of policy authoring. This includes providingpolicy-independent labelstoragein kernel objects,andpersistentstorageof labelsusing file system extended attributes. The TrustedBSD MAC Framework com-posesresults from simultaneously loaded accesscontrol policies in a predictableandreliable manner, permittingappropriately craftedpoliciesto beused in concert.

TheMAC framework augments theFreeBSDkernel to provide commonlabelinginfrastructurealongwith asetof entrypointsto interceptoperationson labeledob-jects. Theframework supportslabelson file systems,processes,IPC,andnetworkstack elements. Eachregistered policy may reserve spacefor security labels andimplement policy-specific behaviorgoverning label content anduse.Labelsfollowthekernel object life cycle andareinitialized, allocated,anddestroyedalong withtheir object. Accesscontrol entrypointsaccept informationabout theaction beingperformed,invokeeachregisteredpolicy, andcomposetheresults into asuccessorfailure.

Thefoll owing table lists theFreeBSDkernel objectsthatcontain MAC labels:

Structure Description

struct ucred Processcredentialstruct file File descriptorstruct vnode VFSnodestruct socket BSDIPC socketstruct pipe IPCpipestruct mbuf In-flight datagramstruct mount File system mountstruct ifnet Network interfacestruct devfs dirent Devfs entrystruct ipq IP fragmentqueuestruct bpf desc BPFpacket sniff device

On-going work with theMAC framework is designedto increasethescope of theaccesscontrol entrypoints. Futureversionswill includesupport for theSystemVIPC kernel subsystemaswell asbetter support for file systemmountpoints; otherkernel subsystemswill be examinedand the access control entry points will berefinedasnecessary. Network AssociatesLaboratorieshasalsobegun work to portthe TrustedBSDMAC framework andthe SEBSD moduleto the Darwin kernel;this will likely result in additional changes to the MAC framework to facilitatecross-platform development.

5

2.2 Linux Security ModulesFramework

The Linux Security Modules(LSM) project was primarily developedby WireXandNetwork AssociatesLaboratories andseeks to incorporate a general securityframework into the Linux kernel. LSM is a joint developmenteffort by severalprojects,includingImmunix,SELinux,andJanus,andseveral individuals, includ-ing Greg Kroah-HartmanandJamesMorris, to develop a Linux kernel patch thatimplements this framework.[9]

While LSM wasoriginally developedasasetof patchesthatmaybeappliedto theLinux kernel distribution, muchof the security framework is now present in thecurrently distributedLinux developmentkernel (2.5.x serieskernels). The LSMframework is primarily focusedon supporting accesscontrol modules,but maybeextendedto support other security needssuchasauditing. TheLSM kernel patchmoved most of the capabiliti es logic into an optional security module,with thesystemdefaulting to thetraditional superuserlogic.

Much like theTrustedBSDMAC framework, LSM addedsecurity fields to kerneldatastructuresandinserted calls to hook functions at critical points in the kernelcode to managethe security fields and to perform access control. It also addedfunctions for registering and de-registering security modules and ongoing workwill provide a generic set of user-spaceinterfacesto set and retrieve labels onkernel objects.

Security fields,thatmaybeusedto storelabelsor any other stateinformation, wereaddedto thefoll owing kernel datastructures:

Structure Description

struct task Processlabelstruct linux binprm Binary handlerstruct super block File system mountpointstruct inode File node(alsosockets)struct file File handlestruct sk buff Network messagebufferstruct net device Network interfacestruct kern ipc perm SystemV IPC objectstruct msg msg SystemV message

By providing security fields for these structuresandby providing appropriateop-erational hooks, an LSM modulecanprovide accesscontrol over processes,pro-

6

grams,file systems,pipes, files, sockets,packets,network devices,andSystemVIPCobjects.

SELinuxwasoriginally developedasasetof patches,directly modifying theLinuxkernel, while morerecent versionusetheLSM framework. BecauseLinux, LSM,SELinuxareall still under development,various versions of SELinuxareslightlydifferent. The Linux kernel is developed with two primary branches,a stablebranch and a current developmentbranch. As developmentcontinueswith theLinux kernel, thestable andcurrent branchestendto diverge. While muchof theLSM prototype hasbeenincluded in the current Linux kernel branch, it is notcomplete; the LSM project still maintains patchesto incorporate the remainingfeatures.Sincelittle of the framework is includedin thestable kernel branch, theLSM project maintains a completepatch.

2.3 Framework Comparison

While theimplementationdetails differ, boththeLinux andFreeBSDframeworksseekto solve the samebasicproblems. Both frameworks permit accesscontrolmodules to be dynamically inserted into an otherwise standardsystem, either atboot time or after boot, possibly in responseto an environmental change. By it-self, neither framework increasesthe security of the system; they merelyprovidetheinfrastructure necessaryto support security modules.Both projectsconsideredmodularity andpolicy flexibility to be critical to the adoption of their respectivesecurity framework by the kernel developers;neither operating systemwantedtobetied to a single security modelor implementation.

Furthermore,both LSM and the TrustedBSDMAC framework operate transpar-ently to existing usersandapplications.Theresults of accesscontrol decisionsareonly visible to applicationsuponfailure,andin mostcases,thekernelserviceswillreturn appropriateerrorcodes thatapplicationsshould expect from anunmodifiedkernel. However, it is possible that security modules will return an access fail-urewherenot previously expected; this maycauseunexpectedside-effects in userspace applications thatarenot security-aware.

While both frameworks hadsimilar goals, the resulting frameworks werelargelyshapedby therequirementsof theuser community. In thecaseof LSM, any designthatwastoo intrusive wasunlikely to beacceptedby theLinux kernel developers,so often sacrifices had to be madein order for the framework to be included inthe kernel. On the otherhand,the TrustedBSD MAC wasdesignedwith a goalof integratingtightly with thekernel locking andthreading mechanismsto provide

7

Use

rP

roce

ss

Use

rP

roce

ss

Use

rP

roce

ss

Use

rP

roce

ss

Use

rP

roce

ss

Use

rP

roce

ssUser Processes

Security Framework

System Call Interface

Kernel Services

Policy Module(s)

VF

S

Pro

cess

LSM Framework

System Call Interface

VF

S

SEBSD

(Policy)

Pip

e IP

C

Sco

ket I

PC

Pro

cess

MAC Framework

SELinux

System Call Interface

Net

wor

k

Sys

tem

V IP

C

Figure1: High-level view of theFrameworks

correctness andhigh performanceon multi-cpu machines.While theLSM projectattemptedto minimizethechangesto thebasekernel, theTrustedBSDMACframe-work wasnot developedunder this restriction,andwasableto restructureexistingkernel codeatplaceswhereaccesscontrol decisionsneeded to bemade.TheMACFramework guaranteesthatsufficient lockswill beheldin orderto accessimportantelementspassed asargumentsto accesscontrol entrypoint functions. Likewise,theMAC Framework provideswell-definedlocking semanticsfor objectlabels, oftenusing existing object locks. Often, the locking semantics permit atomic checksof both labels andexisting object properties without incurring additional lockingoverhead.

Policy composition is integral to the MAC Framework, rather than leaving com-position up to the module writers, asLSM does. LSM chose to allow maximumflexibil ity by creating a truly generic framework that providesall the necessary

8

hooks andlabel management tools, but enforcesno semantics on how they mustbe used. So, while thereis no built-in support for modulecomposition, all thenecessaryhooks arepresent to do so. Whenmultiple policies areloadedinto theMAC Framework, their access control decisions areusefully composed in a waythattheresults arewell-defined.However, this composition is fully controlled andenforcedby theframework, not by thepolicy developers.

To further support policy composition, theTrustedBSDMAC framework alsopro-videspolicy neutral interfacesanduser spacetools. TheMAC framework providesa policy-agnostic labelmanagementAPI to provideaccess to andmanagementoffile andprocesslabels. SeveralFreeBSDcommonutilit y programshavebeenmadelabel-aware(but policy-agnostic),suchasps,ls, andlogin. TheTrustedBSDMACframework hasinvestigatedtechniquesto provide policy-independent support forlogin andother applicationswith morecomplex labeling requirements,such asla-bel transitions at programexecution time. However, not all of thesetechniquesaresufficient for SEBSD. The MAC framework mustbe expandedto include bettersupport for SEBSD-specific features,while maintaining policy flexibilit y, easeofmanagement,andconfiguration.

Both frameworksallow file system labelsto bebacked to persistent storage.Whileneither framework enforces the semantics of particular persistent backing mech-anism, both Linux and FreeBSDcan support both extendedattributesand cus-tom labelbacking stores. TheLinux extendedattributekernel support is relativelynew anduntested,with little userspace managementtools. Historically, SELinuxusedit’s own persistent file label store,ratherthanany providedby the file sys-tem. It is expected that support will improve as the extended attributesystemmatures. FreeBSD’s UFS2 file system provides robust support for extended at-tributes,including centralized cachemanagement for persistentfile labels,aswellas transaction-like support for consistency whenapplying labeling changesfromcompoundoperationsacrossmultiple policies.

The TrustedBSD MAC framework providesboth label management entry pointsand access control entry points. The access control entry points always pass asparametersall information thatmaysafely beused by policy developers.Thesepa-rametersincludetheextracteduser andprocesscredentials, whenavailable.Havingthe Framework pass in explicit label pointersreducesbinary andsourcecompati-bili ty issuesassociatedwith changesto thebasesystemstructures.Thismaylowerdevelopmentcosts andimprove long termmaintainability. In addition, to supporthigh performancereliable operation on multi-CPUsystemstheexplicit credentialis alsousedby FreeBSDto permitdeferredactivity onbehalf of asubject (i.e. NFSwrite-behind, ktrace to a disk file, etc.). The LSM framework typically assumes

9

that object labels may be extracted from the global current processcontext. Thishascausedsomeproblemswith theSELinux network labeling implementation, asthecurrent processis not alwaysavailableor correct.

As an example,the TrustedBSDMAC framework entry point for performing ac-cesscontrol checks for theswapon system event is structuredasfoll ows:

int mpo_check_system_swapon(struct ucred *cred,struct vnode *vp, struct label *label);

WhereastheLSM framework providesthefollowing hook:

int security_swapon(struct swap_info_struct * swap);

The TrustedBSD MAC framework provides the associated usercredentials (andcorresponding processlabel), whereas the LSM hook relies upon the module de-veloper to extractthis information from current (thecurrent processcontext).

3 SELinux

NSA Security-EnhancedLinux (SELinux) is an implementation of a flexible andfine-grainedmandatory accesscontrol (MAC)architecturecalledFlaskin theLinuxkernel[10, 1]. SELinux can enforce an administratively-definedsecurity policyover all processesandobjects in thesystem,basingdecisionson labelscontaininga variety of security-relevant information. Thearchitecture providesflexibility bycleanly separating the policy decision-making logic from the policy enforcementlogic. Thepolicy decision-making logic is encapsulated within asingle componentknownasthesecurity server with a generalsecurity interface.Thepolicy enforce-mentlogic is implemented using the interfacesspecified by the LSM framework.A wide range of security models canbe implemented assecurity serverswithoutrequiring changesto any othercomponentof thesystem.

3.1 Flask

SELinux is basedon the Flasksecurity architecture for flexible non-discretionaryaccesscontrols. The Flasksecurity architecture specifies well defined interfaces

10

to provide a cleanseparation betweenpolicy enforcementandpolicy interpreta-tion. The Flasksecurity architecture alsoincludesan access vector cache(AVC)component to help minimize the performanceoverhead from the access controlcomputation. While policy enforcementcodeis largely systemspecific, policy in-terpretation andaccesscontrol decisionmakingcodeis platform independent. Thepolicy enforcement codeis tightly integrated into the kernel services it protects,andusesthe Flask security server APIs (and the AVC) to obtain security policydecisions.

The Flask security architecture provides two policy-independent datatypes: thesecurity context (context) andthesecurity identifier (SID). Thesecurity context isastring representationof apolicy-specific security label.TheSID is a local integeridentifier thatmaybeusedasarun-timehandle to identify specific security context.Thesecurity server will maintain a setof security classesthat identify the typeofobject being protected;eachsecurity classhasanassociatedsetof permissionsforcontrolling access to theobject. This associatedsetof permissionsis representedasa bitmapcalled anaccessvector.

A Flaskobject manager binds SIDs to active kernel objects,andusestheseSIDsascontext duringaccesscontrol checks. Thepolicy enforcementprovidesasourcecontext, a target context, a security class, andan accessvector to the AVC to de-termine accessto an object. Likewise,whenan object manager wishesto label anewly createdobject, it will consult thesecurity server to obtain a label.

3.2 Modified Programs

TheSELinuxdistribution alsoincludessupport programsandmodifieduser spaceapplications. The support programsinclude a policy compiler, a file system la-beling tool, role management tools, andpolicy querying tools. Severaluser spaceapplications were modified to make them policy-aware. In particular, SELinuxdistributesmodifiedversions of GNU processandfile utiliti es, log rotation pro-grams,the system login program, the openssh server, the tar program,andvixi ecron. Thechangeswereprimarily madeto allow theprogramsto retrieve anddis-play SELinux labeling information, in somecases, allowing programsto maintainexisting labels as files are modified. Othersprograms(login, sshd, cron) weremodifiedto support execution time modification of processlabels.

11

4 SEBSD

This section provides an overview of the SEBSD security modulearchitecture.Much like the SELinux module, TrustedBSD MAC policies arebuilt asloadablekernel modules,relying on theFreeBSDmodulefacilities for linking andloading.

4.1 Distrib ution

Thesourcecodefor SEBSD is distributed asastand-alonekernel module thatmaybe linked against FreeBSD5.x. Typically, it is desirable to include the SEBSDsourcesdirectly in the kernel source tree, in the sys/security/sebsd di-rectory. The SEBSD implementation consists of the samemajor componentsasthe LSM-basedSELinux implementation: the security server, the access vectorcache (AVC), new system call implementations,andthe entry point function im-plementations. Theexception is thefifth elementof theSELinux architecture, theSELinux-specificpersistentlabel mapping,it wasnotportedto FreeBSD,sincetheUFSandUFS2file systemssupportedtheuseof native extendedattributesandtheTrustedBSD MAC Framework providesintegratedsupport for handling extendedattributes. Otherwise, SEBSD literally reuses (almost verbatim) the FlaskAVC,thesecurity server components,thepolicy compiler, andevenmuchof thepolicyitself.

The policy configuration usedby SEBSDis roughly the sameas that providedby SELinux. For the mostpart, pathnameswerechanged to reflecta FreeBSDinstallation. It wasnot thatdifficult to configure thepolicy to support a base con-figuration of FreeBSD,allow it to boot in enforcing mode,and permit userandadministrator login.

4.2 Porting Flask

TheAVC andsecurity serverwereonly modifiedin waysnecessaryto port themtotheFreeBSDoperating system. Compatibility with theSELinuxcomponentswasmaintainedwhenpossible. Changeswerenecessaryto:

� Replacememoryallocations anddeallocationswith a generic wrapper func-tion that implements FreeBSDkernel-specific operations.

� Allow thebinary policy file to beaccessedfrom within thekernel. Theorig-inal LSM-basedSELinux distribution handled policy initi alization in this

12

manner, but hassincemigrated toward a user-spacepolicy loading mecha-nism. It is expectedthatSEBSDwill foll ow theleadfrom SELinuxandwillbemodifiedto no longer directly look up or readthebinary policy file frominside the kernel; the policy will be opened andreadfrom userspace andpassedasa memorymappeddata pointer to thekernel.

� Locking primitiveswereconvertedto FreeBSDequivalents.

� The AVC and the SecurityServer were separated into two correspondingsub-directories(avc andss) within theSEBSD sourcehierarchy; this facil-itateddevelopmentandreducedinter-dependencies.Only FreeBSD-specificcoderesidesat thetop level of thesourcehierarchy.

� Audit information wasupdatedto correctly report details of FreeBSDkerneldatastructures. Sincefull or partial pathnamesarenot readily available intheFreeBSDkernel, file systemandfile identifiers (fsid andvnode) arecurrently reportedby avc audit. Theunavailablity of completepathnamesisa property of theVFS modelemployedby theFreeBSDkernel. While pathnamesarefrequentlyavailable in theLinux kernel, it is not alwayspossibleto reconstruct thecompletepath name.

� The user space interfacesto the SEBSD modulewerere-implemented in ageneric mannerso that they could be madeavailable to all MAC modules.This led to thedevelopmentof interfacesthatusepolicy-independent textualrepresentation for module namesandlabels. This providedthe opportunityto avoid exposingSIDsoutsidethekernel, insteadpassing contexts asstringbasedidentifiers. SELinux lateradoptedthis approach.

Otherthanthechangesabove, themajorcomponentsof theFlaskarchitecturere-mainfunctionally equivalenton FreeBSDandLinux.

4.3 SEBSD Module Initialization

TheFreeBSDmoduleinterfacesallow policy modules to belinked into thekernelatbuild time, loadedprior to thekernel starting atboottime,or loadedat run-time.SinceSEBSDrequires ubiquitous access to all systemobjects, it mustbe presentfrom systeminception; theSEBSD modulemusteither be linkeddirectly into thekernel, or it may be built asa separatedynamickernel module andconfigured toloadprior to kernel execution.

13

The MAC Framework is initialized early in the boot process,shortly after basickernel primitivesareinitialized (memoryallocation, system console, andlockingprimitives),but prior to probing devicesandstarting any kernel or userprocesses.Oncetheframework is initialized, it will allow policy registration. Policy modulesbuilt directly into the kernel will be registeredat this time. Likewise, modulesloadedby theboot loader prior to bootwill beregisteredat this time.

Whenpoliciesregister with theMAC Framework, they provide a numberof prop-ertiesthat areused by theframework to properly identify andconfigurethemodule.Shown belowaretheproperties setby theSEBSD module.

Property Value

ModuleName sebsdFull Name NSA/NAI LabsSecurityEnhanced BSDUsesLabels yesFlags MPC LOADTIME FLAG NOTLATE

In addition to setting the namefor the module,the propertiesrequeststorage forkernel object labels,andsetaflagto indicatethatthepolicy modulemustbeloadedandiniti alizedearly in the boot process. TheNOTLATE flag alsomeansthat at-temptsto register themoduleafterthesystembootwill fail.

4.4 User Interfaces

SEBSDusesboth the system control (sysctl) andsystem call interfacesto allowuserspace processesto accessthe state of the SEBSD module and to query thesecurity server. Library functions, located in libsebsd wrap the sysctls andsystemcalls, providing anAPI that is identical to thatprovidedby SELinux. Thefoll owing list of SELinux APIsaresupported:

int sebsd_enabled(void);

int sebsd_enforcing(void);

int sebsd_load_policy(const char *path);

int get_ordered_context_list(const char *user_name,const char *from_context, char ***ordered_list,

14

size_t *length);

int get_default_context(const char *username,const char *from_context, char **default_context);

int query_user_context(pam_handle_t *pamh,char **ordered_context_list, size_t length,char **retcontext);

security_class_t string_to_security_class(const char *s);

int security_get_user_contexts(const char *fromcontext,const char *username, char ***retcontexts,size_t *ncontexts);

int security_change_context(const char *domain,const char *ocontext, security_class_t oclass,char **newcontext);

int security_compute_av(struct security_query *query,struct security_response *response);

SEBSDchose not to export SIDs from the kernel; userspace applications willonly have access to context strings. TheTrustedBSD MAC framework developedgeneric string-based labelmanagementfacilitiesthatarecompatible with all secu-rity policies. By requiring textual label representationsin userspace,TrustedBSDwasfree to develop applications conforming to a single standard, andusertoolsmay be both label-awareandpolicy-agnostic. The SELinux project seemsto bemoving in this direction aswell, soultimatelythis design will allow theSELinuxandSEBSDinterfacesto converge.

4.4.1 SystemControls

SEBSDusesfive systemcontrols (sysctls) to maintain module stateinformationandto query the security server. The sysctls arewrapped by library functions inlibsebsd. Thesysctls for displaying module state informationmaybequeriedor updated with the normal FreeBSDadministrative tools suchas the sysctlcommand.

15

SystemControl Description

security.mac.sebsd.enforcing Displaystateof theenforcementof policy; allowsmodification to enable/disableenforcement

security.mac.sebsd.sids List SIDSin active useby thesecurity serversecurity.mac.sebsd.user sids Lists theSIDscurrently availablefor transition to

by a givencontextsecurity.mac.sebsd.change sid Report the SID to relabel to given input source

context, target context, anda security class.security.mac.sebsd.compute av Computeaccess vectors given input source and

target contexts,security class, andaccess vector

4.4.2 SystemCalls

The TrustedBSDMAC framework includesan entry point function for a multi-plexed system call. SEBSD is currently using this interface to support the re-loading of security policy after boot time. It is anticipatedthat this interfacewillbeconvertedto a sysctl andthatno SEBSD-specific system callswill berequired.Therearethreesystemcallscurrentlydefined; they arelistedin thefollowing table:

SystemCall Description

int sebsdenforcing() Boolean: is thepolicy beingenforcedint sebsdavc toggle() Togglethestateof theenforcing flagint sebsdload policy(contchar*path) Loadthespecified policy file

4.5 Label ManagementTools

The TrustedBSDMAC Framework provides a numberof policy-agnostic inter-faces for policy-awareapplications; theseinterfacesareavailable in the standardC library. The framework provides interfacesto get and set labels on file sys-tem objects (vnodes), sockets, pipes, and network interfaces. Thesegeneric la-beling servicesareusedto make several basic system binaries policy-aware. TheFreeBSDls andps utilit ies weremodifiedto report file andprocesslabels, andtheifconfig tool wasmodifiedto support network device labels. In addition,several new labelmanagementtools areprovided:

16

Program Description

getfmac Retrieve file labelsetfmac Setfile labelgetpmac Retrieve processlabelsetpmac Setprocesslabelsetfsmac Setslabels on thespecified file systemhierarchy

4.6 SEBSD UserSpaceApplications

TheSELinux policy compiler andinitial file systemlabeling tools wereported tothe FreeBSDoperating system for usewith SEBSD; thesetools wererenamedtosebsd checkpolicy andsebsd setfiles respectively. The policy com-piler is essentially unchanged. The file system labeling tool was re-written tousegeneric file hierarchy traversal (fts) routinesinstead of the Linux nftw rou-tines. This tool wasalsousedasthe basis for a generic file labeling tool, calledsetfsmac, which is ableto apply policy-agnostic labels based on file specifica-tions.

SinceSELinuxandSEBSD only permitprocesslabel transitionsatprogram execu-tion time, theFreeBSDlogin programwasmodifiedto usetheexecve securesystem call to permit new login shells to operate in the proper domain. To showhow thismaybedonefor other applications,thecrondaemon wasalsomodifiedtopermitcronjobsto executewith thecorrect label.Thesechangeshavenotyetbeenadoptedby the TrustedBSDMAC framework, so they areSEBSD-specific appli-cations. In continuing work, the MAC framework will design a policy-agnosticinterfacefor login, providing compatible support.

5 SEBSDLabel Management

5.1 SEBSD Labels

SEBSDmaintains per-objectlabels on processes,pipes, files, file descriptors, andfile systems.Thelabelscontain informationthatSEBSD usesto make access con-trol decisions.Eachof theobject-specific label structuresaredefinedin sebsd labels.h.

17

5.1.1 Process Labels

Thetask security struct, definedin sebsd labels.h, contains secu-rity information for systemandkernel processes.TheMAC framework storestheselabels in theprocesscredential structure.Thestructureis definedasfollows:

struct task_security_struct {security_id_t osid;security_id_t sid;avc_entry_ref_t avcr;

};

Field Description

osid SID prior to thelastexecvesid SID for theprocessavcr AVC entryreference

5.1.2 Mount Labels

TheMAC framework maintains two separatelabels for thekernel mount structure;SEBSDusesthemount security struct to label thefile systemmountpointitself; this label is intendedto beusedto authorize mount,unmount, andstatcalls.Thesecond structure,themount fs security struct, is usedasthedefaultlabel for objectsin thefile system,whenthefile systemdoesnotsupport persistentfile labels. As the TrustedBSD MAC framework matures, this may be controlledfrom userspacewith a mountoption. This would allow the systemadministratorto specify aninitial labelatmounttime. Dueto locking concerns,neither label canbechangedat run-time.

struct mount_security_struct {security_id_t sid;unsigned char uses_psids;unsigned char uses_task;unsigned char uses_genfs;unsigned char proc;unsigned char uses_trans;

};

18

struct mount_fs_security_struct {security_id_t sid;

};

Field Description

sid SID for themountusespsids Flag: this file system supportspersistentSIDsusestask Flag: usecreating taskSID for vnodesusesgenfs Flag: usesecurity genfs sid for vnodesusestrans Flag: whether to call security transition sidproc Flag: whether to call procfs set sid

5.1.3 File and Pipe Labels

Thevnode security struct, contains security information for vnodesandrepresentobjectswithin afile system.This labelstructureis alsousedto labelpipeobjects.

struct vnode_security_struct {security_id_t task_sid;security_id_t sid;security_class_t sclass;avc_entry_ref_t avcr;

};

Field Description

sid SID for thefile (vnode)task sid SID of thecreating processsclass security classof this fileavcr AVC entry reference

5.1.4 File Handle Labels

While it wasnot partof theoriginal design,SELinux’s useof file descriptor labelsprovidedmotivation for theTrustedBSDMAC framework to provide themaswell.This recent addition providesbasicsupport for labeling struct file objectswithin thekernel andallowsfor accesscontrol checks. Thefile security structcontainsonly a single field holding theSID for theobject.

19

struct file_security_struct {security_id_t sid;

};

5.1.5 Network and SystemV IPC Labels

TheSEBSD moduledoesnotyetprovidelabels for network objects,andtheTrust-edBSDMACframework doesnotcurrentlyprovidelabeling or accesscontrol entrypoints for mostof theSystemV IPCsubsystem.A prototypeimplementing accesscontrol entrypoints for theSystemV IPC subsystem is nearly complete,andwillbeintegratedinto FreeBSDaftersufficient testing.

5.2 Label Life-cycle

The TrustedBSDMAC framework manages all labels with a threestatemodelthat closely matches the life-cycle of most kernel objects; labels are initialized,created or associated,anddestroyed. While all kernel objectswith MAC labelshave identical life-cycles, they will differ in the association andcreation phases,since theseoften require object-specific context. For instance, the association oflabels with vnodeswill often be determinedby the capabilities of the underlyingfile system,whether it is read-only or whetherit supports extendedattributes.

Label initialization occurs whenthe datastructure for a kernel object is first ini-tialized. At initialization time, SEBSD dynamically allocatesstorage spaceforper-object labelsandattachesthemin it’s reservedlabel slot.

At label creation or association, a label is bound to a specific kernel object andsomelabelfieldsmaybecompletedbasedon context specific to theobject. Labelcreation takesplacewhenthe modulecreatesa new label valuefor a new kernelobject. This is different from association, which occurs whena previously labeledobject, suchasa file with a persistent label, hasa label associated with it. In thecaseof file objects,theassociation occurs whena persistentobject is readin fromdisk; at this time thepersistent label mayalsoberetrievedandassociatedwith thekernel object.

Labeldestruction occurs whenthekernel object is no longerneeded by thekernelservice; at this time SEBSDfreesany allocatedstoragefor thelabels.

Thefoll owing table lists thevarious label life-cycle entrypoints usedby SEBSD:

20

Entry Point Description

sebsd init cred labelsebsd init mount labelsebsd init mount fs labelsebsd init vnode labelsebsd init file label

Initialize the label for a newly instanti-atedkernel object; memoryfor the labelis allocated

sebsd destroy label Destroy the label on a kernel object andfree any associated memory; this com-mon function is usedfor all entry pointsin the MAC framework that destroy ob-ject labels

sebsd create cred Set the label of a newly created processcredential from theparent label

sebsd create pipe Setthe labelof a newly created pipe,us-ing theSID from thecredentialof thecre-atingprocess

sebsd create proc0 Createtheprocesslabel for process0, theparent of all kernel processes; the SID isinitialized to SECINITSID KERNEL

sebsd create proc1 Createtheprocesslabel for process1, theparent of all userprocesses(init); theSIDis initi alizedto SECINITSID INIT

sebsd create mount Fill out thelabel onthemountpointbeingcreated

sebsd create root mount Initialize theSEBSD security server aftertheroot partition hasbeenmounted; pol-icy is located on root partition

sebsd create file SettheSID of this label to theSID of theprocesscreating thefile handle

sebsd create devfs devicesebsd create devfs directorysebsd create devfs symlink

Complete the file label for thedevfs dirent being created; theseentry points are called when the devicefile system is mounted, regenerated, ora new device is made available; callssecurity genfs sid to generatetheSID for thenew label

21

5.3 Inter nalize/Externalize Operations

In order to translatebetween kernelobject labelsanduserspacetextual representa-tions, theTrustedBSDMAC framework providesentry point functionsto internal-izeandexternalizeprocessandfile labels.SEBSD generatesastringrepresentationof labels by composing themodulenamewith thecontext string; thesecomponentsareseparatedwith a ‘/’ character. Hence,a processlabel would berepresentedas‘sebsd/root:user r:user t’. The internalizeentry points convertsstringsin this formatto a SID.

TheTrustedBSDMAC framework alsosupports internalization andexternalizationof labels on network interfacesandsockets,but sinceSEBSDdoesnot yet addressthenetwork layer, these areunused.

Thefile andprocessentrypoints areasfoll ows:

Entry Point Description

sebsd externalize vnode label Producesa text representation for thefilelabel, alsoused to convert pipelabels

sebsd internalize vnode label Produceaninternal file labelbasedonex-ternalized label datain text format, alsousedto convert pipelabels

sebsd externalize cred label Producesatext representationfor thepro-cesscredential

sebsd internalize cred label Produce an internal process label basedon externalizedlabel datain text format

5.4 PersistentFile Labels

Within the MAC framework, mounted file systemsare either marked as single-label or multi-label; this distinction is madeat mount time. Single-label file sys-temsderive the label for all files from the file system mount point. Labelsonsingle-label file systemsmaynot bemodified. For multi-labelfile systems,thefilesystem is responsible for implementing a per-file source of labels. Typically thisis implementedasfile systemextendedattributes. TheFreeBSDUFS1andUFS2file systemssupport extended attributes andSEBSD usesthese facilities to labelobjects.

The devfs file system, like the Linux implementation, maintains labelsexplicitlythroughtheuseof genfs; theSEBSDpolicy specifies thelabelsto use.

22

Thefoll owing tabledescribeseachof theSEBSD entrypoint implementations thatmanage persistent labels for files.

Entry Point Description

sebsd copy vnode label Copy the label information, alsousedtocopy pipelabels

sebsd relabel vnode Change the vnode label to anew value; only called subse-quent to a successful call tosebsd check vnode relabel

sebsd create vnode extattr Complete the file label for the newlycreated file and write out the label tothe appropriate extended attribute; callssecurity transition sid to gen-erate theSID for thenew label

sebsd setlabel vnode extattr Write the file label to an extended at-tribute

sebsd associate vnode devfs This entrypoint is currently unusedsebsd associate vnode singlelabel Onnon-multilabel file systems,this entry

point setsthe file label based on the filesystemlabel

sebsd associate vnode extattr Attempt to retrieve the file labelfrom the appropriate extended at-tribute; if an extended attribute can-not be located, fallback to usingSECINITSID UNLABELED

6 SEBSDEntry Point Implementation

6.1 ProcessEntry Points

SEBSDprocessentry point functionsmanagesecurity fields for usercredentialsandperform access control for processoperations. Thefoll owing entry points areusedto enforceprocessaccess control decisions.

SinceSELinux andSEBSD only allow processlabelsto changeat programexe-cution time, the MAC Framework relabel entry point is not used. Likewise, therelabel access control entrypoint, sebsd check cred relabel is configured

23

to alwaysdeny requests.

Thechanging of processlabelsat execution time hasprovento besufficiently dif-ferent from thebehaviorof otherMAC policies,thattheTrustedBSDMAC frame-work neededto bemodifiedto support it.

This execution time label modification also tends to be incompatible with largesystems,suchasKDE, which usesa custompre-binding mechanismthatmaynotdirectly invoke execve(). Likewise, relying on exec-only relabeling may causeissueswhenFlask is ported to the Darwin kernel dueto behavior of someof theMacOSX windowcomponents; it mayneed to supporton-demandchangingof thelabel. Whenpoliciesdopermitprocessrelabeling, theMAC Framework doesofferadditional protectionsto prevent attacks againstprocessmemoryandcapabilitiesfoll owing thesubjectlabel change.

Thefoll owing table describesthepermissionsenforcedby processentry points.

Hook Source Target Permissionsebsd check cred relabel N/A N/A alwaysdenysebsd check proc debug credential process ptracesebsd check proc sched credential process setschedsebsd check proc signal credential process signal, sigstop,

sigkill, or sigchld

6.2 Mount Entry Points

Thefollowing operationenforcesaccesscontrol checks whenperforming a statonmountstructures.

Hook Source Target Permissionsebsd check mount stat credential filesystem getattr

6.3 File Entry Points

The SEBSD file entry points perform access on files. The FreeBSDkernel rep-resentation of files anddirectoriesarestored in vnodes; this is the structure thatcontainsthefile label. TheTrustedBSD MAC framework addsentry points to theVFSto control vnodeoperations,andthuscontrol file access.

File labels are protectedby the vnodemeta-data lock, which must be held for

24

these checks. This locking requirementled to thebreakup of therelabel operationinto two separate checks, from andto. It is not possible to hold all vnode locksnecessaryto perform all access control checks in a single entrypoint function.

Thefoll owing table describesthepermissionscheckedfor file operations.

25

Hook Source Target Permission

sebsd check vnode accesssebsd check vnode open

credential file read,write, searchappend,or execute

sebsd check vnode chdirsebsd check vnode chroot

credential directory search

sebsd check vnode create credential directoryfilefilesystem

add name,searchcreateassociate

sebsd check vnode delete credential directoryfile

search, remove name,rmdir or unlink

sebsd check vnode deleteaclsebsd check vnode setaclsebsd check vnode setextattrsebsd check vnode setflagssebsd check vnode setmodesebsd check vnode setownersebsd check vnode setutimes

credential file setattr

sebsd check vnode getaclsebsd check vnode getextattrsebsd check vnode stat

credential file getattr

sebsd check vnode exec credential fileprocessfile

execute no transtransitionentrypoint

sebsd check vnode link credential dirfile

search, add namelink

sebsd check vnode lookup credential dir searchsebsd check vnode mmap credential file read,write, or executesebsd check vnode poll credential file pollsebsd check vnode readsebsd check vnode readlink

credential file read

sebsd check vnode readdir credential dir readsebsd check vnode relabel credential file

filesystemrelabelfrom, relabeltoassociate

sebsd check vnode rename from credential dirfile

search, remove namerename

sebsd check vnode rename to credential dir

file

add name,search,remove namermdir or unlink

sebsd check vnode write credential vnode write

TheSEBSD moduledoesnotcurrently implement thesebsdcheck vnode revoke.

26

6.4 Pipe Entry Points

TheSEBSDpipeentrypointsperform accesscontrol for interprocesscommunica-tion pipes. Thepermissionscheckedfor pipeobjectsaresimilar to thosecheckedfor file objects. Thesepermissionsarelisted in thefollowing table:

Hook Source Target Permission

sebsd check pipe ioctl credential fifo file ioctlsebsd check pipe poll credential fifo file pollsebsd check pipe read credential fifo file readsebsd check pipe relabel credential fifo file

filesystemrelabelfrom, relabeltoassociate

sebsd check pipe stat credential fifo file getattrsebsd check pipe write credential fifo filey write

6.5 File Handle Entry Points

TheSEBSDfile handleentrypointsperform accesscontrol for file descriptor oper-ations.Eachstruct file structurecontainsstatesuchasthefile offset andfileflagsfor openfiles. Sincefile descriptors may be shared amongst processeswithdifferentsecurity attributes, accessto themmustbecontrolled.

Thefoll owing table describesthepermissionsenforcedby file entrypoints.

Hook Source Target Permissionsebsd check file create credential fd createsebsd check file get flagssebsd check file get ofileflagssebsd check file get offsetsebsd check file change flagssebsd check file change ofileflagssebsd check file change offset

credential fd use

6.6 SystemV IPC

The TrustedBSD MAC framework doesnot currently support labeling of SystemV IPC objects or provideaccesscontrol entry points. Whenthis kernel subsystemis fully supportedby theTrustedBSDMAC framework, SEBSD will beupdated.

27

6.7 Network Support

While the TrustedBSD MAC framework provideslabeling andaccess control fornetwork devices,sockets,andmessages, the SEBSDmodule does not yet imple-mentany of theseentry point functions.

6.8 MiscellaneousModule and SystemEntr y Points

Theseentry point functionsarecalled to register andde-register the the SEBSDmodule. Thefoll owing tablelists theseentrypoints,alongwith thegeneric systemcall entry point.

Entry Point Description

sebsd init This entry point is currently unused;the SEBSDmoduleinitializes itself whentheroot file systemis mounted

sebsd destroy This entry point is currently unused; when theSEBSD module registers with the MAC frame-work, configuration parameters specify that theframework should not permit theSEBSD modulefrom being unloaded

sebsd syscall This entry point provides a policy-multiplexedsystem call so that SEBSD may provide addi-tional servicesto userprocesseswithout register-ing specific systemcalls

The following table lists the permissionsenforcedby miscellaneous system andmodule access control entrypoints.

Hook Source Target Permission

sebsd check kld loadsebsd check kld unloadsebsd check kld stat

credential capability sys module

sebsd check sysarch ioperm credential capability sys rawiosebsd check system acct credential capability sys pacctsebsd check system reboot credential capability sys bootsebsd check system settime credential capability sys timesebsd check system swaponsebsd check system swapoff

credential file swapon

28

Two system entrypoints,sebsd check system sysctl andsebsdchecksystem nfsdarenot yet implemented; they control complex operations andrequire further re-search.

6.9 Entr y Point Comparison

While Linux andFreeBSDboth providea similar useroperating environment, thekernel services are ratherdifferent, and the kernel implementations aredramati-cally different. As a result, there is no convenient way to comparethe LSM andTrustedBSD MAC frameworks at the entry point (hook) level. Both frameworkssupport labeling operationsandaccesscontrol checks on file andprocessobjects,but theorganizationof theindividualkernel services(processandVFS)caused thetwo security frameworksto diverge.However, since thesamebasicoperationsarebeing performed,thesamesetof permissionswasapplicableto both SEBSD andSELinux. OncetheSEBSD prototypeis complete (including network andSystemV IPC support), a full analysis canbe doneto verify that the permissionsbeingenforcedby SEBSDarecomparableto those enforcedby SELinux.

7 Futur eDevelopment

The SEBSDmoduleis still under development; labels arenot maintained on allkernel objects supported by the TrustedBSDMAC framework, andnot all accesscontrol entry points have beenimplemented. However, the current stateis suf-ficient to prove that the Flask architecture is sound and that it translateswell totheFreeBSDplatform. Going forward, SEBSD will provide labeling support andaccess control checks for network objects, pipe objects, and SystemV IPC. Inaddition, the following list summarizesthe itemsthat arecurrently scheduled forinclusionin thenext majorreleaseof SEBSD:

� Provide morecomplete path information in avc audit messages. Currentlythe FreeBSDVFS doesnot provide complete path information, only filesystemandfile identifiers are reported. Thereareseveral approaches thatmaybetaken to improve pathidentification.

� Re-implementpolicy loading mechanisms.Takingtheleadfrom theSELinuxproject, SEBSD will likely implement a userspacepolicy loading mecha-nism.

29

� SynchronizetheAVC andSecurity Server. SinceSEBSDoriginally branchedfrom the SELinux developmenttree, the SELinux project hasmademanychanges and improvements; SEBSD needs to make certain all importantchangesmadeto thesecurity server andtheAVC arere-integrated.

� Synchronize userspaceAPIs. Recentuserspace API changesin SELinuxneedto beexamined in greater detail, andanattempt will bemadeto bringthetwo APIsasclosetogetheraspossible.

� File system/mount point hooksare incomplete. Therearesomeremainingtechnical issues with the ways the TrustedBSDMAC framework handlesmountpoints andmountpoint accesscontrol checks.

8 RecentLinux Changes

Because SELinux and the LSM framework areboth still works in progress,thecode baseoriginally adaptedfor SEBSD hasdiverged from the current SELinuxdevelopmentbranch. Recentchangesto SELinuxinclude:

� All API calls werechangedto passcontexts rather thanSIDs. As this wasalready the interfacethat SEBSD chose, there is littl e impact due to thischange – rather it bringsthetwo userspace APIsclosertogether. By havingthetwo APIsalign, it will allow easier porting of security-awareapplicationsandUnix tools.

� Extendedsystem calls for passing in asecurity context atprogramexecutiontimeandobject creation timewerereplacedwith asequenceof systemscallsthat first seta security context foll owed by the operation. At this point theMAC framework (and SEBSD) only makes useof the execve secureextendedsystemcall; theMAC framework hasaddedthissystemcall. Sincethe TrustedBSD MAC framework does not yet permit atomic object cre-ation and labeling system calls, the new SELinux interfacewill be exam-ined in greater detail to determine whether this approachwill work well onFreeBSD.

� Theextendedstatsystemcallswerereplacedwith separate,orthogonalsys-temcalls thatonly obtain thesecurity context. This is already theapproachtakenby theTrustedBSDMAC framework.

30

� All calls that returncontexts or context arraysnow provide automatic allo-cationof context buffers andcontext arraybuffers of the proper size. Thissimplifiesthe interface,asuserapplications no longer mustguessan initialsizeandretry with a larger bufferuponfailure. SEBSDimplementsmany oftheseinterfacesassysctls, so it maynot be appropriateto allocate memoryon behalf of thecaller – this issue will beexaminedin further detail.

� The policy loading API takes a (data, size) pair ratherthan a Unixpathname.TheSELinuxmodule no longerdirectly opens files from withintheLinux kernel. With thenew interface,a user spaceapplicationwill openthe file, mmapit, and call security load policy with a pointer tothe policy data. Sinceit is preferableto avoid file accessfrom within theFreeBSDkernel, it is likely thatSEBSD will take this approachaswell. It ispossible that the TrustedBSD MAC framework will needto be modifiedtosupport this behavior.

For the mostpart, these changeswill bring the userspace APIs for SEBSD andSELinux closer together. The otherchangesto SELinux arelikely to be adoptedby SEBSD, andwith theuseof a userspacesecurity library, remaining API differ-ences maybeabstracted,allowing user applications to remainlargely compatible.

9 Getting the Software

TheTrustedBSDMAC Framework, aswell asanumber of samplepolicy modules,are present in the FreeBSD5.0 distribution. This software may be downloadedfrom:

http://www.FreeBSD.org/

TheMAC Framework is distributed under atwo-clauseBerkeley-styleopen sourcelicense,permitting unlimitednon-profit or for-profit reusein bothopensourceandclosed source products. Additional information on the TrustedBSDProject andSEBSDmaybefoundat:

http://www.TrustedBSD.org/

Much of theLSM Framework is currently includedin the current Linux develop-mentkernel releases.This software maybedownloadedfrom:

http://www.kernel.org/

31

Additional informationabout theLSM Framework is availableat:

http://lsm.immunix.org/

TheSELinuxsoftwareanddocumentation is available at:

http://www.nsa.gov/selinux/

References

[1] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lep-reau, “The FlaskSecurityArchitecture:SystemSupportfor DiverseSecurityPolicies,” in 8th USENIX Security Symposium. Washington, D.C., USA:USENIX, Aug. 1999, pp.123–139.

[2] P. Loscocco andS.Smalley, “Integratingflexible support for security policiesinto theLinux operating system,” U.S.National SecurityAgency, Tech.Rep.,Oct.2000.

[3] “FreeBSDhomepage,” FreeBSDProject,http://www.FreeBSD.org/.

[4] TrustedBSD Project, “TrustedBSD home page,”http://www.TrustedBSD.org/.

[5] R.Watson,“IntroducingSupporting Infrastructurefor TrustedOperating Sys-temSupportin FreeBSD,” in BSD Conference, Monterey, CA, USA,October2000.

[6] ——, “TrustedBSD: Adding Trusted Operating System Features toFreeBSD,” in Proceedings of the USENIX Annual Technical Conference, June2001.

[7] R. Watson,B. Feldman, A. Migus, andC. Vance,“Design andImplementa-tion of theTrustedBSDMAC Framework,” in DISCEX III, Washington,DC,USA, April 2003.

[8] R. Watson,W. Morrison, C. Vance,andB. Feldman,“The TrustedBSDMACFramework: Extensible KernelAccessControl for FreeBSD,” in Usenix An-nual Technical Conference, SanAntonio, TX, USA, June2003.

[9] “Linux Security Moduleshomepage,” LSM Project, http://lsm.immunix.org/.

32

[10] P. A. Loscocco andS.D. Smalley, “Integrating Flexible Support for SecurityPolicies into the Linux Operating System,” in Proceedings of the USENIXAnnual Technical Conference, June 2001.

33