Cambridge Security Group talk

Cambridge Security Group talk

[Russell Coker]

The talk seemed to go quite well.

The lecture theater could hold 150+ people and was more than half full at the 
start, very few people left early, and I think that the main reason for 
people leaving early was the fact that I exceeded the alotted time.

The audience asked some really technical questions about issues such as the 
way crond determines the correct security context for a process it runs (I'm 
not certain that I managed to convey the details of that one well to the 
audience, it's difficult to explain without diagrams or code).  I think that 
perhaps I should start a frequently asked really technical questions to 
address such issues.

One issue that drew a number of comments from the audence was the length of 
security contexts and the amount of typing that it can involve.  One audience 
member said "space in an Xterm is precious", another audience member 
mentioned having three servers without X that were not administered remotely 
(IE everything is done at the console without even an X based cut/paste 
facility).

One suggestion from the audience was to remove "_t" and "_r" suffixes as the 
context has all the information necessary to differentiate domains from 
roles.  Another suggestion was to remove some parts of the context when they 
aren't needed (such as object_r).  I tried this once but Steve convinced me 
to revert it.  I am now thinking that perhaps we should review this matter.

In regard to the permissions on files, it was pointed out in a quite clear 
fashion that standard Unix has 10 characters in the "ls -l" output to specify 
the permissions.  Of course this is ignoring the user and group fields which 
combined make it into a text representation almost as long as a security 
context.  On my laptop the average length of security contexts I have in use 
at the moment is 30.5 characters including the two ':' characters.  For unix 
permissions it's 10, plus 5 for the group, plus <=8 for the user-name which 
is 25 characters if we include two separators.

The audience had no comments on the issues related to default contexts, 
however they have my email address and hope that at some future time someone 
will have some ideas and email them to me.

There was a suggestion that I should write a magazine article about what I did 
with my SE Linux play machine.  When I was doing it, it didn't seem THAT 
exciting to me.  But if people want to learn more then I'm happy to oblige.  
I'll hunt around and see if someone is interested in publishing such an 
article.

Also an audience member asked me if it would be possible to run a machine with 
all files and processes UID=0, which was a strange co-incidence as I have 
been planning to do that for play machine ][ (but I may have mentioned it on 
a mailing list or something and the word may have got around).  This idea 
seemed to get a lot of interest from the audience, who seemed to actually 
want to do it as a serious way of running a system (rather than as a fun 
demonstration of the power of SE Linux).  But I can oblige.  It wouldn't be 
THAT difficult to modify "ls -l" to display link-count, security-context, 
size, date, and name, and to make similar changes to ps etc to not bother 
displaying UID/GID.  Then cron etc could be modified to run all jobs under 
the same UID etc.  The passwd wrapper would also work if the UID checks were 
made a configuration option (could be made a PAM module).


Anyway, I highly recommend that any of you who are in the Cambridge area 
attend a meeting if possible, and give a presentation if you are working on 
something that intersts them.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Tom]

On Sat, Jan 18, 2003 at 01:49:27AM +0100, Russell Coker wrote:
> One issue that drew a number of comments from the audence was the length of 
> security contexts and the amount of typing that it can involve.  One audience 
> member said "space in an Xterm is precious", another audience member 
> mentioned having three servers without X that were not administered remotely 
> (IE everything is done at the console without even an X based cut/paste 
> facility).

One partial solution (for those of us using it) would be to make bash's
"tab complete everything" feature aware of security contexts. It's
already pretty powerful (e.g. on an scp it can tab-complete remote
paths, for many programs it can tab-complete commandline parameters,
etc)

Another partial solution are aliases. For example, I have aliases for
ls --context and ps --context.


> Also an audience member asked me if it would be possible to run a machine with 
> all files and processes UID=0, which was a strange co-incidence as I have 
> been planning to do that for play machine ][ (but I may have mentioned it on 
> a mailing list or something and the word may have got around).  This idea 
> seemed to get a lot of interest from the audience, who seemed to actually 
> want to do it as a serious way of running a system (rather than as a fun 
> demonstration of the power of SE Linux).  

Well, essentially it would condense the current 2D matrix we have on
permissions back to a one-dimensional system, only along the other
axis.

It would definitely be interesting for embedded systems, consoles and
other stuff that doesn't really have very much of a user concept. For
example, the iPAQ distribution (familiar) runs everything as root
unless you install some add-on packages.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Brian May]

On Sat, Jan 18, 2003 at 04:45:55AM +0100, Tom wrote:
> One partial solution (for those of us using it) would be to make bash's
> "tab complete everything" feature aware of security contexts. It's
> already pretty powerful (e.g. on an scp it can tab-complete remote
> paths, for many programs it can tab-complete commandline parameters,
> etc)

On Debian (at leat Debian, probably any system), there is a directory,
/etc/bash_completion.d/ where packages can put scripts to enable
"non-standard" command line completion. It would appear to be very
powerful, and should be able to cope with any situation (I think).

It doesn't help me though, I use zsh...
--
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Brian May]

On Sat, Jan 18, 2003 at 01:49:27AM +0100, Russell Coker wrote:
> One suggestion from the audience was to remove "_t" and "_r" suffixes as the 
> context has all the information necessary to differentiate domains from 
> roles.  Another suggestion was to remove some parts of the context when they 
> aren't needed (such as object_r).  I tried this once but Steve convinced me 
> to revert it.  I am now thinking that perhaps we should review this matter.

I think the benifit of the _t and _r suffixes isn't so much to aid
to computer, but to make the policy more readable by the human user.

> In regard to the permissions on files, it was pointed out in a quite clear 
> fashion that standard Unix has 10 characters in the "ls -l" output to specify 
> the permissions.  Of course this is ignoring the user and group fields which 
> combined make it into a text representation almost as long as a security 
> context.  On my laptop the average length of security contexts I have in use 
> at the moment is 30.5 characters including the two ':' characters.  For unix 
> permissions it's 10, plus 5 for the group, plus <=8 for the user-name which 
> is 25 characters if we include two separators.

I think that the "standard" ls -l output is going to be less important
when 2.5.x is finally released with ACL support...

Which raises another interesting topic, that is 2.5.x supports attrs
(EAs) on ext2 and ext3 (at the minimum; I don't know about reiserfs),
maybe SE-Linux security contexts could be stored in attrs?
--
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Cambridge Security Group talk

[Florian Hines]

By any chance is there a streaming media recording of the Cambridge seminar
? Or is there plans for a live web cast once ? (Through Flashcomm or
something)...or a speaking engagment in the South Western US.  I'm stuck in
San Antonio, TX so not much chance of me making it to europe till next
summer. 

Just curious,

Florian Hines


---
Treadhead's aren't born, they're made!
			--  Polaris owners
---



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Russell Coker]

On Sun, 19 Jan 2003 07:13, Florian Hines wrote:
> By any chance is there a streaming media recording of the Cambridge seminar
> ? Or is there plans for a live web cast once ? (Through Flashcomm or

As far as I am aware there was no such recording.

My talks for OLS 2002 and Debconf 2002 in Toronto were both recorded but have 
not been released.  I have asked the people who made the recordings for the 
mp3's to be released to me (if no-one else), but I have not received a 
response.

> something)...or a speaking engagment in the South Western US.  I'm stuck in
> San Antonio, TX so not much chance of me making it to europe till next
> summer.

If air-fares and accomodation are paid then that can probably be arranged.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Root-only systems

[forrest whitcher]

On Sat, 18 Jan 2003 04:45:55 +0100 
Tom <tom@lemuria.org> did inscribe thusly:

> On Sat, Jan 18, 2003 at 01:49:27AM +0100, Russell Coker wrote:
> > Also an audience member asked me if it would be possible to run a machine with 
> > all files and processes UID=0, which was a strange co-incidence as I have 
> > been planning to do that for play machine ][ (but I may have mentioned it on 
> 
> Well, essentially it would condense the current 2D matrix we have on
> permissions back to a one-dimensional system, only along the other
> axis.
> 
> It would definitely be interesting for embedded systems, consoles and
> other stuff that doesn't really have very much of a user concept. For

This is one way to go, and I think it has potential value as you say in
embedded systems.

I'm actually trying to go the other direction, and remove some of the 
Unix/Posix root concepts. Presently the lsm/selinux checks are run in
addition to the unix uid/gid checks, failing either can deny the 
privelege.

As a strong tool is in place, why for instance do we still want to 
require UID=0 to bind a low-number network port or access device 
drivers etc?

Otoh, I expect the number of places where UID=0 checks have been 
built into both the kernel and userspace tools may make practically
eliminating root from low-level operations a bit of a stretch.


forrest

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Root-only systems

[Russell Coker]

On Tue, 21 Jan 2003 01:31, forrest whitcher wrote:
> I'm actually trying to go the other direction, and remove some of the
> Unix/Posix root concepts. Presently the lsm/selinux checks are run in
> addition to the unix uid/gid checks, failing either can deny the
> privelege.
>
> As a strong tool is in place, why for instance do we still want to
> require UID=0 to bind a low-number network port or access device
> drivers etc?

One really good reason is the way that SE Linux is deployed on running 
servers.

If I have a running machine then I can't entirely rebuild it immediately, so I 
install SE Linux in permissive mode, and apart from the potential of someone 
typing "avc_toggle" at the wrong time it'll keep running as before.

If we allow non-root to bind to low ports (for example) then permissive mode 
would be significantly less secure than a non-SE machine.  If we don't allow 
such operations in permissive mode then permissive and enforcing modes will 
be functionally different.

Also once we have a system running in enforcing mode we know that if the SE 
Linux policy fails us then we still have Unix permissions.  If we weaken the 
standard Unix permissions then new users will not be granted the assurance of 
"the worst security problem it can have is to run like a regular Unix 
system".

> Otoh, I expect the number of places where UID=0 checks have been
> built into both the kernel and userspace tools may make practically
> eliminating root from low-level operations a bit of a stretch.

The issue of binding to low ports is not difficult to fix.  The other big one 
is setuid(), the rest probably don't matter much.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Stephen D. Smalley]

> One issue that drew a number of comments from the audence was the length of 
> security contexts and the amount of typing that it can involve.  One audience 
> member said "space in an Xterm is precious", another audience member 
> mentioned having three servers without X that were not administered remotely 
> (IE everything is done at the console without even an X based cut/paste 
> facility).

How often does a user need to type a context?  Typically, labeling of
processes and objects is handled transparently to the user.  newrole
only requires you to enter the new role name.  Editing the policy
configuration or file contexts configuration can be done offline,
and shouldn't be too frequent anyway.

> Another suggestion was to remove some parts of the context when they 
> aren't needed (such as object_r).  I tried this once but Steve convinced me 
> to revert it.  I am now thinking that perhaps we should review this matter.

libsecure provides some functions for manipulating security context
fields that are used by newrole and runas.  In general, you want to
encapsulate any logic that knows about the syntax and semantics of the
security context in a library and avoid policy-specific knowledge in the
application unless the application is fundamentally policy-specific.

> Also an audience member asked me if it would be possible to run a machine with 
> all files and processes UID=0, which was a strange co-incidence as I have 
> been planning to do that for play machine ][ (but I may have mentioned it on 
> a mailing list or something and the word may have got around).  This idea 
> seemed to get a lot of interest from the audience, who seemed to actually 
> want to do it as a serious way of running a system (rather than as a fun 
> demonstration of the power of SE Linux).  But I can oblige.

I can't recommend this.  You would need to audit your policy
configuration very carefully in light of the fact that SELinux would be
providing the sole authoritative decision for Linux capabilities
(similar to
http://marc.theaimsgroup.com/?l=selinux&m=102614635816689&w=2), and you
would need to audit any applications that make hardcoded assumptions
about uid 0.  Also, if your system is intended to be multi-user, you will
still want a DAC mechanism for user-defined restrictions.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Stephen D. Smalley]

> Which raises another interesting topic, that is 2.5.x supports attrs
> (EAs) on ext2 and ext3 (at the minimum; I don't know about reiserfs),
> maybe SE-Linux security contexts could be stored in attrs?

Yes, we're looking into the use of EAs for file security contexts.
We would still retain the persistent label mapping as a fallback if
the filesystem didn't support EAs.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Russell Coker]

On Tue, 21 Jan 2003 18:48, Stephen D. Smalley wrote:
> > Which raises another interesting topic, that is 2.5.x supports attrs
> > (EAs) on ext2 and ext3 (at the minimum; I don't know about reiserfs),
> > maybe SE-Linux security contexts could be stored in attrs?
>
> Yes, we're looking into the use of EAs for file security contexts.
> We would still retain the persistent label mapping as a fallback if
> the filesystem didn't support EAs.

I think it would be good to have a migration strategy from PSID to xattr in 
this case.  We need a way to convert a system from PSID to xattr without 
down-time (IE it must be possible to convert the root file system without 
having to boot with a different root fs).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Cambridge Security Group talk

[Russell Coker]

On Tue, 21 Jan 2003 18:42, Stephen D. Smalley wrote:
> > One issue that drew a number of comments from the audence was the length
> > of security contexts and the amount of typing that it can involve.  One
> > audience member said "space in an Xterm is precious", another audience
> > member mentioned having three servers without X that were not
> > administered remotely (IE everything is done at the console without even
> > an X based cut/paste facility).
>
> How often does a user need to type a context?  Typically, labeling of
> processes and objects is handled transparently to the user.  newrole

There are times when you boot in single-user mode and need to relabel files.

> only requires you to enter the new role name.  Editing the policy
> configuration or file contexts configuration can be done offline,
> and shouldn't be too frequent anyway.

True, policy editing can usually be done from an xterm, although there are 
people who don't have this luxuary.

Another thing, when using a keyboard displayed on a 240x320 TFT display with a 
stylus typing in the current context names is going to be painful...

> > Another suggestion was to remove some parts of the context when they
> > aren't needed (such as object_r).  I tried this once but Steve convinced
> > me to revert it.  I am now thinking that perhaps we should review this
> > matter.
>
> libsecure provides some functions for manipulating security context
> fields that are used by newrole and runas.  In general, you want to
> encapsulate any logic that knows about the syntax and semantics of the
> security context in a library and avoid policy-specific knowledge in the
> application unless the application is fundamentally policy-specific.

What about a bash plugin for it?  I believe that bash supports writing plugins 
for the TAB key to complete various operations, which could probably be 
extended for this.

> > Also an audience member asked me if it would be possible to run a machine
> > with all files and processes UID=0, which was a strange co-incidence as I
> > have been planning to do that for play machine ][ (but I may have
> > mentioned it on a mailing list or something and the word may have got
> > around).  This idea seemed to get a lot of interest from the audience,
> > who seemed to actually want to do it as a serious way of running a system
> > (rather than as a fun demonstration of the power of SE Linux).  But I can
> > oblige.
>
> I can't recommend this.  You would need to audit your policy
> configuration very carefully in light of the fact that SELinux would be
> providing the sole authoritative decision for Linux capabilities
> (similar to
> http://marc.theaimsgroup.com/?l=selinux&m=102614635816689&w=2), and you
> would need to audit any applications that make hardcoded assumptions
> about uid 0.  Also, if your system is intended to be multi-user, you will
> still want a DAC mechanism for user-defined restrictions.

I agree in concept, however we have to consider the following three issues:

Embedded devices run everything as root and so does Lindows.  SE Linux on such 
machines can only do good.

If we independantly verify that both SE permissions and Unix permissions are 
each capable of meeting the base security goals on their own then the result 
of combining the two of them will be better still.

In many production systems it's necessary to have SUID root programs for tasks 
such as starting chroot environments.  Not all of them will be written by 
good programmers.  If we design SE Linux to withstand free root access then 
it will stand up to the inevitable failures of SUID root programs.


That said, I have a SE machine online right now with everything as root.  It 
is a very untrusted machine, it has no passwords that are similar to 
passwords on trusted hosts, and it has firewalls to stop it attacking 
machines inside or outside my network.  I recommend that machines with such a 
configuration be locked down in such a fashion.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Cambridge Security Group talk

[selinux+Steven.Murdoch]

> By any chance is there a streaming media recording of the Cambridge seminar

There are no official audio or video recordings of the seminar and, 
as far as I know, no independent ones were made either.

However the abstract for the talk is available at:
http://www.cl.cam.ac.uk/Research/Security/seminars/2003/2003-01-17.html
and the slides used are at:
http://www.cl.cam.ac.uk/users/sjm217/security-group/talks/cl03selinux-coker/

Steven J. Murdoch
Security Group,
University of Cambridge, England.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.