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

[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.