Chris Wright: presented an overview of the LSM project. None of it
should be news to regular readers of this list.
------------------------------------------------------------------------
A New Security Architecture for Hosting Internet Services
What is HP-LX?
* a highly secure version of Linux for running applications and
services
* building on the success of HP VirtualVault
o balance ease of use with security
o a new security model focused on internet services and
applications
* minimal kernel changes
* HP will deliver
o sample applications, e.g. apache
o ...
HP-LX In Context
* graph that looks a lot like ours
Review of Major Features
* containment
* file system protection
* system configuration lockdown
* audit
* secure administration
* future features
Containment
* major feature of the product
example of compartment communciation rules
* host:*-> compartment rules ...
Audit
* stripped down version from VirtualVault
Secure administration
* based on SSH
Future Features
* patch checking and system scanning
* application integration tool
* more sophisticated compartment management tools
o currently just have command line utilities
* management
o integration with popular managment platforms: OpenView, etc.
* Secure networking
o distributed containment
* fial-over support
* intrusion detection
* more applications
------------------------------------------------------------------------
SELinux
Stephen Smalley, NAI
What is SELinux
* Implementation of flex., fine-grained nondiscretionary access
controls for linux
* clean sep. ..
Why would you want to use it?
* to confine malicious mobile code that exploits a flaw in your web
browser
* to confine an exploit of a flaw in apache, bind, sendmai, or any
other system service
* to prevent unauth. mods of your system software, config files, and
logs
* to protect e confidentiality or integrity of sensitive info
* to safely run a program of uncertain pedigree
* ...
SELinux and LSM
* SELinux orig. impl as a kernel patch
* presented at 2.5 kernel summit
* linus provided feedback on what he is willing to accept into the
kernel: a comon set of kernel hooks that can support many diff.
security projects
* LSM is a communit effort coord. by WireX to devle a kernel patch
that provides such hooks
* ...
Questions?
* SELINUX: www.nsa.gov/selinux
* LSM lsm.immunix.org
------------------------------------------------------------------------
Testing and Verification for LSM
Trent Jaeger and Antony Edwards IBM Research, T.J. Watson Lab
Placement, Verification, Management of Kooks is Key
* Hooks in front of dangerous operations within the kernel
* hooks call out to the LSM module(s)
* risk: hooks may not be close enough to dangerous operations to
effectively prevent damage
Tools We Are Working ON
* Initial concern: correctness and ease of hook management
o cna reasonabele management toolset be created
* top-down: hook, location -> identify protected op
o static, sanity check, documentation, limited static regression
* Bottom-up: dangerous op, location -> runtime security context
o runtime, correctness, regression
Top-down Hook Analysis
* for each hook in LSM kernel: find location, logical operation,
protected operation
* location, logical operation are in hook
* how easy is it to deduce the protected operation?
* generally easy except for implicit, misordered variables,
intermediate variables, and optimized cases
* express consistently but remove overhead via tools
Bottom-Up Analysis
* for each dangerous operation
o determine the security contexst for the operation
o compare to the expected security context
* how do we identify dangerous ops?
o security updates, function ptrs for modules
o instruction location, symbol of interest
* what determines a correct authorization?
* ...
------------------------------------------------------------------------
Linux LSM at SGI
Richard Offer, SGI
goals: evaluatable configurations
* CAPP: Existing Linux Access Control + Audit
* LSPP: Mandatory Access Control + Audit
* Native implmentation of POSIX MAC and audit
Pre-LSM Audit
* CAPP
o functionally complete since fall 2000 [2.2]
o ported to 2.4.5 bewfore LSM started
o code comprised
+ kernel "hooks" created, filled and finalized records
+ audit library [POSIX API]: 95% shared source
+ kernel component
+ user-land component
+ audit aware applications, e.g. LILO
CAPP Audit as an LSM Policy
* Redesign under LSM as a work in progress
o LSM hooks
+ only fill in record
o new syscall handler creates & finalizes records
+ requires learning assembler for all [supported]
platforms, but small enough to bear ongoing maintenance
costs
* LSM makes it easier to distribute new policies
Problems:
* Restrictive vs Authoritative Hooks
o Position of hooks
+ wagner/jones proposal seems workable to everyone's equal
dissatisfaction. But no progress made
* Kernel logic moved to module
o no solution, linux 3.0?
* module interfaces
o /pro, system call?
Applications have policies too
* ld: get and show process attributes
* ls: get and show file attributes
* sendmail: is recipient cleared for e-mail?
* X: can cut-n-paste between windows [classic CMW]
------------------------------------------------------------------------
Hot Issues
* name vs. inode (hopefully moot
* ordering of in-kernel and in-module check
o restrictive vs. authoritative
* push in-kernel out (not looking favarable
o CONFIG_LSM
* runtime identificaton of module
* syscall interface
* feedback on cool new netowrk hooks
* what to do w/ capabilities module?
* UNIX domain sockets using abstract namespace
* submit patch?
name vs. inode
* need some way to recover the absolute path name of the file
requested by the application
* problematic in 2.4
* good news: in 2.5 the permission() call will provide both the vfs
mount point and the dentry, which will allow modules that need it
to get either the pathname or the inode
* Q: why are there not read and write hooks?
* A: because read and write call permission, so one hook in
permission satisfies.
Ordering of in-kernel vs. module check
* problem: some projects want DAC (in-kernel) checks done first,
while others want MAC (module) checks done first
* conjectured solution:
o do DAC checks first
o convert all the hooks to be "authoritative", where the DAC
result is given to the module, which makes the final
determination.
o place additional hooks so that "short circuit" cases where the
kernel does a DAC-deny early pass that result to the module
* Problem with the conjectured solution: the "short circuit" hooks
are numerous, and potentially complex.
o Crispin: can we supply semantically simpler hooks for the
short-circuit cases, so the kenrel is only sending the DAC
return code to the module for post-processing? Problematic.
o Stephen: how about using the capable() hook to always return 1
ofr CAP_DAC, which effectively turns off ALL in-kernel DAC
logic, and punts the problem to the module. This makes it
possible for SGI to do what they want, at the cost of
re-implementing DAC logic in the module.
* Action: SGI should look at Stephen's early June authoritative
patch, and determine to what extent it will satisfy their needs.
To the extent that it falls short, SGI should identify what is
needed in addition. It is important that the cases SGI looks at
not be just the simple ones; there are hard cases that need to be
examined.
Push in-kernel logic out to a module: no
Make it possible to config away LSM
* Linus: no conditional compilation
* Ted: urges us to make LSM config-awayable. It's oky to put
#ifdef's in header files
* We can do it either way, but would rather not do it both ways just
to guess which is right.
* Action: reply to Ted that the current impl. is not consistent with
his configable suggestion, and ask him to clarify.
Runtime Module Identification
* We want to have a syscall interface for applications to explicitly
interact with modules.
* Some applications want to know whether there is a particular module
loaded.
* Some systems (SELinux) pass a module identifier as one of the
arguments.
* Stephen wants a convention that one argument is a magic number used
to identify the module. So long as this is strictly a convention,
and has no impact on the LSM code per se, there is nothing to
object to. There are two code requirements:
o Change the syscall interface from (int, vector) to be (int ,
int , vector). Stephen will (by convention) use the extra int
as a module identifier, but the LSM interface won't know that,
it will just pass it through.
o Ensure that the LSM dummy module returns ENOSYS appropriately
when the syscall is called.
Without making it to the end of the Hot Topics list, we ran out of time
& patience, and ajourned. But at least we resolved several important
issues.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Aug 15 2001 - 18:16:45 PDT