SELinux Symposium Notes: Session 7

[Editor's note: It's almost over! Since I had to bail on Session 8 to catch my flight back to Indiana, this is the last set of notes I was able to take. My handwriting gets worse and the content gets more terse with each set. Insert disclaimer here. Enjoy.]

Lessons Learned Developing Cross-Domain Solutions on SELinux (Karl MacMillan et. al., Tresys Technology)

for high-security or untrusted compartmentalized environments
primary goals: confidentiality (H -/-> L) & integrity (L -/-> H); use information flow pipeline
CDS breaks BLP, Biba models — want to control flows, not prohibit outright
let SELinux do the heavy lifting; minimize what app has to do; but apps do need to do transfer policy (e.g. “documents have no executable content” done by app, but SELinux can force filter to be used)
control access to domains to prevent uncontrolled information flows
use multiple localhost aliases (separately labeled) for network-based IPC among local compartments
one-way IPC w/o covert back channels (e.g. timing)? most design for bidi IPC
existing policies often more permissive than strictly necessary — not consider narrow flows
TE works very well for CDS & assured pipelines

Lopol: A Deductive Database Approach to Policy Analysis and Rewriting (Aleks Kissinger et. al., University of Tulsa)

lightweight, interactive, iterative, based on logic programming (Datalog)
operates on policy.conf, translate rules into relations
Datalog evaluation on binary decision diagrams
analysis by forming rules & running queries (primitive rules: reads, writes, [transitive] flows)
generic rules: privileged types, trusted intermediaries, …

Attack-based Domain Transition Analysis .(Susan Hinrichs et. al., University of Illinois at Urbana – Champaign)

what happens if a domain is coopted? information flows, domain transitions (transitively)
look at what a domain can read and write, considering transitions
global domain transition graphs large — domain not bounded as much as we’d like
graph shallow and very wide
consider subgraphs starting at suspect domains & end at sensitive domains
edges: cut edges along paths, or log more carefully, or disable when under threat (via boolean)
nodes: study domain & verify it can’t be misused, insert high-assurance proxy, split domain

Comments Off

SELinux Symposium Notes: Session 6

[Editor’s note: Is he seriously still typing up the notes he scribbled down during the talks at the SELinux Symposium earlier this month?! Doesn’t he know they’re not even necessarily reliable and shouldn’t be used for anything more than recreational reading?]

Experience Implementing a Higher-Level Policy Language for SELinux (Chad Sellers et. al, Tresys Technology)

SELinux has MAC foundation; HLL represents different paradigms, reaching new users, new features
CDS describes information flows, targeted at app developers — compiler & IDE
domains — active entities/security perimeter; shared resources — passive, for domain interaction
access — r/w/rw b/t domain & shared objects
decomposition of domains for better least privilege
challenges: concepts (idealized) v. SELinux details, must integrate w/ base policy [CDS only for cross-domain, not the whole thing]
e.g. IPC not labeled a priori but by creator, same label = equivalent — control resources share label w/ domain and are individually unique
SELinux has many ways to label files, but too complex for HLL; but paths aren’t enough
idea: paths label directories only, sidestepping many issues (leakage, existence, etc.)
hooking into base policy: wrap resource in “baseresource” to define r/w access to it; singleton (likewise for basedomain)

SENG: An Enhanced Policy Language for SELinux (Paul Kuliniewicz, Purdue University)

[Editor's note: Sorry, no notes for this one. I must not have been paying attention.]

Guided Policy Generation for Application Authors (Brian Sniffen et. al., MITRE Corporation)

policy creation/management tools, looking at information flow goals
guided automation, least privilege in use, not toal capabilities of app
idea: find patterns in program behavior, ask writer if things look reasonable
polgen specification language to describe architecture of app
suggest additions from execution traces — limits to how app will be used
can recognize ~12 patterns of operation

Comments Off

CERIAS Symposium

Today (Wednesday) was the second last day of the annual CERIAS Symposium at Purdue University. I only remembered it a little before noon on Tuesday. That’s what being on break for a week will do to your brain, I guess.

Anyway, I didn’t miss the poster session early Tuesday afternoon, where I had a poster on my SELinux policy language work. Fortunately there weren’t many periods of standing around waiting to be asked a question. About half of that question-answering time was spent explaining what SELinux is rather than talking about my work in particular, though.

Sometime in the near future there should be copies of the posters available on the symposium website. People who registered for the conference already got copies as part of their information packets. One nifty thing is that instead of distributing them on CD like last year, they gave each registrant a 128 MB USB flash drive with the posters on them. So, now I have a USB flash drive. Not too shabby, especially when the registration fee is waived for Purdue students.

My main disappointment with the symposium was that a lot of the sessions were very Purdue-centric. It makes sense that CERIAS would be showcasing the work going on here, but it means that a large number of the talks are ones I’ve already heard before. The forensics panel Wednesday afternon was pretty good, though; not coincidentally, it consisted mostly of people from government and industry in the field, instead of being dominated by our professors and grad students.

The final talk on comprehensibility of privacy policies was discouraging. In a nutshell, The Privacy Place did some surveys on how people reacted to and understood privacy policies, both in their “natural” language (read: lawyerese) and in altered formats intended to make them more understandable. The results were that, although people better understood the policies when presented in categorized or annotated forms, they believed they understood the current “natural” language style and believed they were more comprehensive than the other forms.

So, what does this mean? My interpretation is, you’re screwed either way. If the company is honest and wants the visitor to understand the policy, in theory they should use a categorized format, but people erroneously perceive it as less useful than “natural” language. Since the intent behind the privacy policy is to make the visitor comfortable with disclosing information, it’s in their best interests to target perceived, rather than actual, comprehensibility. And if the company is dishonest and wants to sneak odious terms in, their best bet is a long-winded monolithic policy that people will think is comprehensive but probably won’t even bother reading. In either case, the status quo is maintained.

Comments Off

SENG Compiler and Examples

I’ve finally uploaded a copy of the proof-of-concept SENG compiler and some examples of using it to write policies.

For the uninitiated: SENG is an experimental language for writing SELinux policies. In a nutshell, it augments the existing language with higher-level constructs aimed at eliminating the need for macros. It was first presented publicly at the SELinux Symposium earlier this month.

The compiler source code and examples are stored in a Bazaar-NG (a.k.a. bzr) repository. If you don’t already have a bzr client installed and can’t get one from your Linux distribution of choice, follow that link to download one. That done, all you need to do is get started is run the following to check out the latest copy:

$ bzr get

To bring that copy up-to-date, go into the directory you checked the code out to and run:

$ bzr pull

That’s it! There’s a couple README files included that should give you enough to get started. To build the compiler, you’ll need Java 1.5 as well as Ant and JavaCC.

I hope to flesh out the (admittedly meager) example as time goes on, but in the near future homework will be claiming more of my “free” time.

I apologize for the delay in getting this out, but there were some problems with the code that needed fixing before showing it to the world.

Comments Off

SELinux Symposium Notes: Session 5

[Editor's note: still more notes taken during the talks at the SELinux Symposium earlier this month. For entertainment use only.]

Keynote Address:UK e-Government: Security Challenges and Solutions for Innovative Service Delivery (Dr. Steve Marsh, UK Cabinet Office)

2000 — put all govt services online by 2005; govt must meet citizens’ needs
requires entire process change to shared services, not just putting up web pages; could save 10%
fun fact: recenue from online crime in US exceeds drug trafficking — suggests risks at play
public sector, man-in-street don’t know how to secure infrastructure, but not just an IT dept problem
must secure govt services and assure public it’s secure — if not used, investment is wasted
testing sees if code behavior matches requirements; doesn’t check for security faults & unexpected behavior
products becoming more complicated, & lifecycle shorter than time need to evaluate their security
locking machine away fails due to networking; air gaps not practical for public services
remote access + secure network = difficult but necessary; esp w/ mobile code; from walls to communities of interest
public sector, public don’t expect to run into barriers day-to-day — have to implement domain separation?
separate networks, VMs to isolate apps; lockdown removes functionality and tends to break apps –> MAC better
crime follows value; can’t let crime erode confidence in govt services — need cost-effective technologies for security
domain separation needed to protect supply chains
[Q: how does compartmentalization hinder operations in emergencies (e.g. Katrina)? A; need to evaluate the risk that a security mechanism blocks business]

Case Study: Open Source and Commercial Applications in a Java-based SELinux Cross Domain Solution (Boyd Fletcher, Joint Forces Command – Joint Experimentation Directorate, USA)

sharing information across networks & classification/information domains
want to securely share as much information with as many people as fast as possible
allow only desired flows and verify only valid, clean data is being moved
TE MAC simplifies the problem; allows assured pipelines to be constructed & reduces burden of software developer (can lock down & isolate parts)
chat tool: operates at ingress & egress of box, though for historical reasons not truly a secure pipeline
in Java, need init scripts & jar files for proper domain assignment; improperly handled exceptions leads to fail-open
commercial apps often ill-behaved but can be constrained by policy; leverages all aspects of SELinux
minimize technical expertise to deploy system

Case Study: Enhancing IBM Websphere with SELinux (Marc Hocking, Technology Cabinet Office, e-Government Unit, UK; Karl MacMillan, Tresys Technology, USA, and Doc Shankar, IBM, USA)

goal: access to data “anytime, anywhere, anyhow” by UK govt user to departmental data in a low-assurance env
federated identity among departments, central authorization w/ permissions decided by depts
desired capability: access to system throughout UK, providing mobility & disaster recovery
support of above UK program & explore SELinux with complicated middleware
sandboxing, enforce n-tier architecture, network security at process level (per-app firewall)
allow Websphere admin to specify security configuraiton, w/o SELinux-specific expertise
and support full Websphere functionality
problem: current SELinux policies are rigid and inflexible, difficult to customize in app-specific, & changes require writing policy
soln: run Websphere-specific tool to take description of app & emit refpol modules, packages for each system

Comments Off

SELinux Symposium Notes: Session 4

[Editor's note: more notes taken during the SELinux Symposium earlier this month. Insert standard disclaimer of accuracy here. My notes from this session are less detailed than for the others, too.]

Progress of SELinux Policy Editor (Yuichi Nakamura, The George Washington University, Hitachi Software)

[for full effect, read the following with microphone feedback in the background]
editor for simplified SELinux policy — path-name based, reduced set of permissions
18% permissions removed — unused, DAC-related, redundant

SLIDE: An Integrated Policy Development Environment (James Athey, Tresys Technology)

Eclipse plugin for refpolicy development
set of usual IDE features, module browsers, etc.

Integrating Multi-Category Security into Fedora (James Morris et. al., Red Hat)

MCS uses categories, not sensitivities, complements targeted policy (better for commercial users) discretionary/advisory scheme
some discretionary control (mail, labeled printing, etc.)

Protecting the Internet from Zombie Armies with DeSPAC-SE (Eric Freudenthal, University of Texas at El Paso)

end user can’t write policy, wants to download & run code off the internet w/o labeling manually appropriately
idea: automatically determine & install labels for downloaded data
on exec of unknown file, query agent to classify it (but assumes agent knows …)
based on virus scanner model

A User-Space Monitor for High-Assurance Workflows (Jacques Thomas, Purdue University)

use MAC to generate control flow through workflow, a la Clark-Wilson, including SoD
high assurance in demand (e.g. Sarbanes-Oxley) — workflow protection all the way down
flexible framework makes auditing easier
workflow split into separate, individually confined tasks; only valid transitions are allowed

Playing Well With Others: Implementing CIPSO on Linux (Paul Moore, HP)

CIPSO labels IPv4 packets using options (e.g. MLS labels, TE types)
Linux currently lacks interoperable support for labeled networking
original attempt rejected (too invasive); now try using LSM hooks

Setools: Current Status and Future Directions (Kevin Carr, Tresys Technology)

enhancing sediff, seaudit; add sechecker
sediff used to help refpolicy transition; visualization & filtering improved
sechecker checks for common policy errors (e.g. incomplete permissions, lack of domain/type separation)

Comments Off

SELinux Symposium Notes: Session 3

[Editor's note: More notes taken during the talks at the 2006 SELinux Symposium. Use at your own risk, etc., etc.]

Reference Policy for Security Enhanced Linux (Chris PeBenito et. al., Tresys Technology)

goal: make policy understandable; close-coupling means developers must understand entire policy
3rd parties need to be able to create policy modules — lack of understanding hurts security
refpolicy reduces complexity & exploits software engineering: documented, modular, configurable
core infrastructure is mature, large # of modules (70%)
security goals: OS self-protection, secure extensability (protect code & modules from each other), assurance, improved role separation (not there yet)
loadable modules, enhanced support for tools, managing complexity, better comprehension, single unified src
design concepts: layering, modularity, encapsulation, abstraction (all “enforced” by convention) [eventually native language support...]
layering only organizational
modules have private code, public interfaces, labeling statements — no global types/attributes

Dynamic Policy Enforcement in a Network Environment (Mark Butler et. al., University of Tulsa)

booleans + expert system to switch security states based on observed state of system (events – IDS/logs)
tools to let admin associate events & booleans to modify
agent collects “facts” (events or static) as system runs, & generates boolean changes
requires a large amount of initial configuration

SELinux Protected Paths Revisited (Trent Jaeger, Pennsylvania State University)

network MAC, client-server MAC forking new procs based on client’s label, location-independent MAC (access control follows objects across networks)
leverages labeled IPSec for secure communications
get label of network peer to make decisions (via getsockopt)
goal: distributed (n-machine) MAC & protected paths & authenticated communication
protected paths between users (even more than app-to-app) — i.e. can we trust the labels we get?
challenges: user-to-app (X server, WM); app-to-OS (labeled IPSec); OS-to-OS (refmon, labels, remote attestation, secure hardware)
secure coalition system — VMs running within a coalition using MAC & between coalitions
distributed, shared reference monitor: VM hypervisor, labeled IPSec to secure inter-VM communications, all w/ common MAC policy
VMs allow coarser-grained policy & simpler reference monitor
build trust from secure hardware up

Comments Off

SELinux Symposium Notes: Session 2

[Editor's note: more notes taken during the talks given at the 2006 SELinux Symposium. There are probably errors and they are definitely incomplete. Use at your own risk, etc.]

Moving FLASK to BSD Systems (Chris Vance, SPARTA, Inc.)

no perfect security model or policy for all applications –> want framework, not direct kernel mods
good design durable — don’t reinvent wheel; get frameworks correct, then use them
split policy from enforcement; port Flask framework to other kernels’ MAC framework
FreeBSD servers, OS X desktop, but shared heritage
Mach IPC – 1000s msgs/sec to secure; BSD, I/O Kit, Mach all have syscall interfaces
Flask, TE stuffed into MAC module; userspace easily ported, no special kernel headaches
LSM less invasive; MAC provides more hooks — different despite similar goals
Darwin: ubiquitous app-level IPC, bleeding b/t BSD & Mach
BSD coverage fairly complete; Mach experiment

Design and Implementation of the SELinux Policy Management Server (Karl MacMillan et. al., Tresys Technology)

incremental deployment & customization of policy; foundation of loadable policy modules
policy access control, not current all-or-nothing model
fine granularity of modifications made to policy — facilitates local mods (e.g. network contexts)
policy controls policy access — class user, class type, etc., & policy components are labeled
metapolicy to specify how domains are allowed to modify the policy
policy hierarchy restricts scope of modifications (e.g. child can’t exceed perms of parent)
policy mgmt server has same libsemanage interface, enforces metapolicy
future: network policy mgmt
(“metapolicy”: small subset of overall policy in most cases)

Towards Automated Authorization Policy Enforcement (Vinod Ganapathy, University of Wisconsin (et. al. from Pennsylvania State University))

i.e., where do we install hooks into a kernel or user app? how to build them?
(security-aware apps need to ask for policy decisions too for app-level objects) e.g. X
common features: multiple clients, shared resources, operations on behalf of clients
building security-aware apps: proactive or retrofit legacy code: add ref mon checks to code
insight: security-sensitive operations have fingerprints; how to find them? how to use them?
use: locate using static analysis, and add hooks at those locations
find: analyze runtime traces & compare them to shorter traces, paring down to the fingerprint (which traces contain the operation must be given)
must know what the security-sensitive operations are conceptually, but not their implementation

Comments Off

Planet SELinux

Apparently this blog is now being syndicated on Planet SELinux.

Thanks to whomever added me, though you’ll probably want the SELinux-specific feed instead of the Coding one that (as of this writing, at least) is currently being syndicated.

Hopefully I’ll get a chance soon to finish posting my notes from the symposium and put up some more SENG-related materials, but right now things like homework and midterms are taking up most of my time.

Comments Off

SELinux Symposium Notes: Session 1

[Editor’s note: these were notes I took during the talks given at the SELinux Symposium. The nodes probably have errors and are definitely incomplete, so don’t go treating them as canonical sources of information or anything. Enjoy the behind-the-scenes peek at how I take notes: a minefield of lousy formatting disjointed grammar.]

Keynote Address: The Road to Practical Mandatory Security in Mainstream Operating Systems – an historical perspective (Steve Walker, Steve Walker & Associates)

research into building security into OSes never got into mainstream systems
world isn’t going to build many more new OSes…
[fun fact: "Al Gore invented Internet" jokes still not funny]
NSA acquiring whatever computer hardware they could purchase (no OSes – none existed yet, largely – just hardware)
on to ARPA, in charge of security stuff
Multics origin of many ideas, but never became mainstream – targetted non-mainstream hardware
UNIX developed –> KSOS effort to make secure kernelized OS – never caught on
as with multi-level VMs, secure XENIX (acquired by TIS), trusted Mach (B3) (died because buzz around NT, not UNIX)
SELinux the exception? (Red Hat backing) – bringing security to mainstream OS
network security:
sending classified data over ARPAnet – encryptors keyed using paper tape, only point-to-point
no control cables around crypto in theory, but did it in practice (covert channels)
limitation: getting multiple copies of paper-tape key – led to developing built-in crypto
DoD using ARPAnet instead of separate network sank funds into Internet’s development
fun fact: TIS hosted originally until White House set up connectivity –> June ’93 + 20 months (messages put on floppies, send to White House for volunteers to answer)

SELinux Year in Review (invited talk) (Stephen D. Smalley, NSA)

year ago: distro support either optional ad-on or with limited scope (eg only server environments)
now: coverage expanded in Fedora, becoming mainstreamed in Debian & elsewhere
MLS, auditing: enhanced & increasingly mainstreamed; RHEL5 undergoing evaluation
monolithic & static policy w/ little, ad-hoc customization –> modules, refpolicy, management APIs (foundational support is now there to build on)
labeling: not for networking, nonatomic file labeling, etc –> new overcome
future: distributed mgmt, IDE, protecting networks, desktop support & protecting app-level objects (SELinux aware apps…), etc

Back from the SELinux Symposium

In case you couldn’t tell from the last post, I’m back from this year’s SELinux Symposium.

The talk I gave went very well. My approach towards improving the policy language seems to have struck a chord with quite a few people there; whereas most other efforts at policy languages are geared either towards policies for individual applications or only provide a subset of SELinux’s power, SENG aims at being suitable for anything without sacrificing power. If the existing policy language is like assembly, SENG is like C whereas other efforts are sort of like Python.

People from Tresys, MITRE, and elsewhere were interested in what I’ve been doing. The downside to that is now I need to get moving making things available for people to look at and play with.

My paper is published in the Proceedings of the Second Annual Security Enhanced Linux Symposium, pages 49 through 53.

Copious notes on the seven sessions I attended (having had to skip the eighth in order to catch my flight back) will be forthcoming. But for now, here’s a grab-bag of random stuff.

The hotel charges guests $10/day for Internet access. The conference organizers tried to negotiate access for the attendees, but the hotel wanted $2000/day for that. At lunch some of us plotted next time for someone to pay for a connection and secretly hook up an access point for everyone else to use.

The PGP/GPG key fingerprint I carry around in my wallet finally got used, when somefrom from the Air Force Research Lab and I traded signatures. He then proceeded to spin a copy of Advanced Programming in the UNIX Environment, 2nd Ed. on one finger above his laptop. When I said that might not be a good idea, he then spun his laptop on one finger.

The desktop background on the computer the MITRE guys used to demo the latest generation of their policy generation tool? Touched By His Noodly Appendage

Stephen Smalley, despite what you’d expect, looks nothing like your stereotypical fat bearded UNIX geek.

… There’s loads more, but that’s all that comes to mind at the moment.

SENG Presentation Slides

The slides from my presentation at the SELinux Symposium are up.

Comments Off