IBM's Multics paper

IBM's Multics paper

[Tracy R Reed]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

As seen on slashdot today...

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485256C2C004B0F0D/$File/RC22534.pdf

I read the entirety of the first paper and parts of the second paper which
is the original Multics vulnerability analysis.

At the top of page 3 of the report (page 5 in your pdf viewed) they
specifically mention SE Linux. They compared Multics 768k bytes of
executable code and data 1767k bytes and suggest that it is far too big to
be secure and that the complexity leading to that large size needs to be
corrected. I infer that due to the Linux kernels monolithic design that
this may not be possible.

Is it realistic to compare a modern OS to Multics? Of course the logical
requirements of multi-level OS security haven't really changed in 28 years
and there is no reason why it should take more bytes to implement the same
ideas so perhaps they are right.

It is also noted that their system never had any exploitable buffer
overflows found due to the way the hardware segmentation worked, the
direction the stack grows (away from occupied stack space instead of
towards such as on x86), the implementation language which has much
better array bounds handling, and the fact that the hardware would not
allow you to execute memory marked as data.

There isn't much we can do about the hardware, stack direction, or
implementation language at the moment. We are stuck with x86 and C for a
good long time it seems. But doesn't x86 hardware now have the ability to
prevent execution of data? That's what Solar Designers patch does iirc.
But there has been some reason for not making it part of the standard
kernel. I've heard about how it prevents intentionally executing
trampoline code on the stack which some compilers use etc. but I have also
heard that this can be fixed. Of course I recall Linus saying that if we
disabled data execution on the stack they would just code around it. I
don't understand how they would do this and if they could do it on x86
surely they could have done it on Multics unless it were very difficult
and if it is that difficult then by all means include the patch in the
kernel! I seem to recall a very long debate about this on the linux-kernel
list some years ago. I have also heard people say that you can get around
the stack direction growth problem although I don't understand how.

I think it is very interesting how Russell's paper "Partioning a Server
with NSA SE Linux" starts out with "The requirement to purchase multiple
machines is often driven by the need to have multiple administrators with
root access who do not trust each other" when that is basically what the
original Multics paper started out with also. The reason they were looking
into multi-level security with mandatory access controls was so that they
could allow secret, top secret, and perhaps even unclassified users, to
all use the same system and thus greatly cut down on hardware acquisition
costs. Having secret, top secret, and unclassified users on one box sounds
rather like you would want them all in their own chroot'd environments or
UML sessions. But from the point of view of the Multics designers, the
steps required to set up domains/chroots or UML etc. are a rather large
kludge with such complexity that it is impossible to verify that all of
the code works as it should with no back doors or unintended side effects.

The parallels between then and now (27 years later) are striking. It is
rather depressing that we are still trying to solve the same problems they
were trying to solve and end up reinventing the wheel.  What's worse is
that our wheel may be rather rickety compared to theirs.

-- 
Tracy Reed      http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior vice-president in charge of Microsoft's Windows development 5 Sept 2002

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: IBM's Multics paper

[Russell Coker]

If we're going to have much discussion about this then it may be best to move 
it to my selinux-talk mailing list, selinux-talk-request@coker.com.au for 
subscription requests.

On Tue, 10 Sep 2002 01:35, Tracy R Reed wrote:
> As seen on slashdot today...
>
> http://domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485
>256C2C004B0F0D/$File/RC22534.pdf
>
> I read the entirety of the first paper and parts of the second paper which
> is the original Multics vulnerability analysis.
>
> At the top of page 3 of the report (page 5 in your pdf viewed) they
> specifically mention SE Linux. They compared Multics 768k bytes of
> executable code and data 1767k bytes and suggest that it is far too big to
> be secure and that the complexity leading to that large size needs to be
> corrected. I infer that due to the Linux kernels monolithic design that
> this may not be possible.

I wonder how they got those numbers, from dmesg on one of my systems:
Memory: 256388k/262080k available (929k kernel code, 5304k reserved, 356k 
data, 84k init, 0k highmem)

So it's 929K of code and 356K of data by my count...

A SE Linux policy may be 2-3M for a fully configured system, but I've cut it 
down to as little as 300K uncompressed.

Also I think it's a really bad idea to count policy and code size at the same 
time, they are different things with different issues.  Code size (which is a 
serious issue) is related to the problems of auditing all that C code and 
making sure it does what it's supposed to do, and it comes from many 
different people with different skill levels...  Policy has to be audited, 
but it comes from a much smaller group of people, it's always checked by at 
least two people with the way things work now, and the people who are writing 
the sample policy know what they are doing.

> There isn't much we can do about the hardware, stack direction, or
> implementation language at the moment. We are stuck with x86 and C for a
> good long time it seems. But doesn't x86 hardware now have the ability to
> prevent execution of data? That's what Solar Designers patch does iirc.
> But there has been some reason for not making it part of the standard
> kernel. I've heard about how it prevents intentionally executing
> trampoline code on the stack which some compilers use etc. but I have also
> heard that this can be fixed. Of course I recall Linus saying that if we
> disabled data execution on the stack they would just code around it. I
> don't understand how they would do this and if they could do it on x86

The recent OpenWall patches include trampoline support.  I've run it on some 
production servers and have not been able to find any problems caused by it.

Hopefully at some time in the near future we'll be able to combine this with 
SE Linux, or even better if we could have functionality equivalent to PAX in 
GRSEC.  http://www.grsecurity.net/

The reason it's easier for Multics is that the hardware supports it, there are 
less bits used for storing page access in i386 and some of these things have 
to be hacked (EG by giving the code and data segments different memory 
mappings such that the code segment doesn't have the stack).  It's really 
ugly.  Hopefully new CPU architectures such as IA64 and IA32-64 will have 
better support for such things.  I'm afraid that I can't recall the exact 
details of the CPU mechanisms involved, one book that I can't recommend 
highly enough is "A Guide to RISC Microprocessor Architecture" edited by 
Michael Slater.  It's an old book which probably isn't in print but should be 
in any good university library.  It is really good for background knowledge 
on how different CPUs do some of these things and why they do it, compare 
that with any book on the i386 (there are many) and you can get some good 
ideas on the relative merits of the CPUs.

Also as mentioned in the document there is a language issue, C is not the best 
language for reliable code.  If we started writing everything in Ada then 
things would become much more secure.

> The parallels between then and now (27 years later) are striking. It is
> rather depressing that we are still trying to solve the same problems they
> were trying to solve and end up reinventing the wheel.  What's worse is
> that our wheel may be rather rickety compared to theirs.

It's not surprising really.  Secure systems never entered the mainstream, so 
people with security knowledge didn't pass it on outside the security 
community.  Until recently most universities didn't even have a shadow 
password file on their time sharing machines!  How could they ever teach 
students anything about security?!?!

Some universities are offering info-sec courses, which I expect to be useless.  
You can't have a situation where there's no semblance of security and then 
just have a lecturer give some talks on security and hope for a good result!

I've been thinking about offering some university lectures on the topic of SE 
Linux.  The idea is a lecture for all 300+ students in the course, then a few 
tutorials for a couple of classes of students that have special interest in 
the area, they would then setup some SE server machines for the other 
students to use.  This could fit into a regular Unix course at any Uni 
(instead of boring the smarter students with tutorials on basic C coding etc 
they can do more interesting things such as learning SE Linux).

This will result in the students learning a lot about security, especially 
when as part of their practical work they have to put machines online and 
issue a public challenge to crack them...

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.


--
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: IBM's Multics paper

[Stephen Smalley]

On Mon, 9 Sep 2002, Tracy R Reed wrote:

> At the top of page 3 of the report (page 5 in your pdf viewed) they
> specifically mention SE Linux. They compared Multics 768k bytes of
> executable code and data 1767k bytes and suggest that it is far too big to
> be secure and that the complexity leading to that large size needs to be
> corrected. I infer that due to the Linux kernels monolithic design that
> this may not be possible.

IMHO, the comparison in the first paper seems very odd.  I take their
point to be that SELinux is far from being a small, verifiable,
security kernel.  No kidding.  You can see that simply by looking at the
size of the base Linux kernel, although that size can vary depending on
your particular kernel configuration.  It also seems questionable to blend
the example policy size with the module size, as the example policy can be
easily stripped down for a particular system and is merely an access
matrix.  If you are going to incorporate that kind of information into
your size estimate, then you had better also include the size information
for all of the ACLs stored on a Multics system.

> Is it realistic to compare a modern OS to Multics? Of course the logical
> requirements of multi-level OS security haven't really changed in 28 years
> and there is no reason why it should take more bytes to implement the same
> ideas so perhaps they are right.

SELinux provides flexible support for mandatory access controls, which is
more than just multi-level security.  Other non-discretionary access
control models like TE and RBAC offer definite benefits.

The authors' position doesn't seem constructive.  Advocating work on
structuring new systems around a security kernel is fine, but attacking
efforts to incrementally improve the security of existing systems is not
helpful.  It also seems questionable that the two examples of security
kernels (VAX VMM, GEMSOS) that the authors hold up as models for
commercial products happen to have been developed by the authors
themselves.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com













--
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: IBM's Multics paper

[Trent Jaeger]

                                                                                                               
                                                                                                               
                                                                                                               


Hi,

I am not one of the authors of this paper (Paul Karger on the cc is), but I
gave Paul the numbers for the SELinux policy.

The numbers for this paper are from the policy files, policy.conf
(pre-processed), and ss_policy (compiled) and they are for the complete
SELinux example policy as stated in the paper.

I agree that the policy can be cut-down (and should be based on your
security target), but I am not aware of any principled approaches for
cut-down. This is the interface that administrators see at present.

Personally, I believe that access decisions must be made at the SELinux
policy level, but I think that the point that Paul is trying to make is
that  strong security guarantees must be expressed in a way that average
system administrators can maintain (many folks on this list are well above
average :->).  I don't think that the strong system security guarantees in
Multics were dependent on the fine-grained policy, so this should not be
the case for SELinux either.

A number of folks are awarelooking into policy management, but let me just
update you on my recent efforts that are consistent with this discussion. I
am doing a simple Biba integrity verification on the Apache policy relative
the rest of the SELinux example policy (assuming trusted system and
authentication services).  Interestingly, the only violations are: (1)
shared files: /tmp, tmpfs_t, writeable_t; (2) a number of logging and
system status files; (3) interactions with many services that would not be
run with Apache (possible cut-downs).  Shared /tmp is a well-known UNIX
problem, but its solution is independent of SELinux (although it would be a
significant benefit).  Log files could be handled as exceptions, likely,
although I am still looking at this.

An issue that I am interested in is policy interactions with other
services.  For example, sendmail can edit files in /etc that Apache is
permitted to read.  This could be handled by editing the policy, but if you
are running a highly secure Apache server do you really want to run
sendmail too?  Rather than editing the policy to create your own
specialized, possibly ad hoc policy, might it be possible to create
"conflicting subjects" that are not permitted to run together.  Thus, the
current SELinux policy would remain largely unchanged, but the security
guarantees that this policy implements can be understood and verified
against the SELinux policy.

Then, the policy that the TCB depends on might include only a high-level
Biba lattice, some verified exceptions, and some conflicting subjects.
This would be much smaller than the entire SELinux policy (and Multics),
but you would still have the fine-grained control that you really need to
ensure the higher level requirements.

Does this seem like a reasonable direction?  Does this interact with the
other work on policy management for SELinux?

Regards,
Trent.
----------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
jaegert@watson.ibm.com
(914) 784-7225, FAX (914) 784-7595



Russell Coker <russell@coker.com.au>@tycho.nsa.gov on 09/10/2002 05:19:12
AM

Please respond to Russell Coker <russell@coker.com.au>

Sent by:    owner-selinux@tycho.nsa.gov


To:    Tracy R Reed <treed@ultraviolet.org>, SE Linux
       <selinux@tycho.nsa.gov>
cc:
Subject:    Re: IBM's Multics paper



If we're going to have much discussion about this then it may be best to
move
it to my selinux-talk mailing list, selinux-talk-request@coker.com.au for
subscription requests.

On Tue, 10 Sep 2002 01:35, Tracy R Reed wrote:
> As seen on slashdot today...
>
>
http://domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485
>256C2C004B0F0D/$File/RC22534.pdf
>
> I read the entirety of the first paper and parts of the second paper
which
> is the original Multics vulnerability analysis.
>
> At the top of page 3 of the report (page 5 in your pdf viewed) they
> specifically mention SE Linux. They compared Multics 768k bytes of
> executable code and data 1767k bytes and suggest that it is far too big
to
> be secure and that the complexity leading to that large size needs to be
> corrected. I infer that due to the Linux kernels monolithic design that
> this may not be possible.

I wonder how they got those numbers, from dmesg on one of my systems:
Memory: 256388k/262080k available (929k kernel code, 5304k reserved, 356k
data, 84k init, 0k highmem)

So it's 929K of code and 356K of data by my count...

A SE Linux policy may be 2-3M for a fully configured system, but I've cut
it
down to as little as 300K uncompressed.

Also I think it's a really bad idea to count policy and code size at the
same
time, they are different things with different issues.  Code size (which is
a
serious issue) is related to the problems of auditing all that C code and
making sure it does what it's supposed to do, and it comes from many
different people with different skill levels...  Policy has to be audited,
but it comes from a much smaller group of people, it's always checked by at
least two people with the way things work now, and the people who are
writing
the sample policy know what they are doing.

> There isn't much we can do about the hardware, stack direction, or
> implementation language at the moment. We are stuck with x86 and C for a
> good long time it seems. But doesn't x86 hardware now have the ability to
> prevent execution of data? That's what Solar Designers patch does iirc.
> But there has been some reason for not making it part of the standard
> kernel. I've heard about how it prevents intentionally executing
> trampoline code on the stack which some compilers use etc. but I have
also
> heard that this can be fixed. Of course I recall Linus saying that if we
> disabled data execution on the stack they would just code around it. I
> don't understand how they would do this and if they could do it on x86

The recent OpenWall patches include trampoline support.  I've run it on
some
production servers and have not been able to find any problems caused by
it.

Hopefully at some time in the near future we'll be able to combine this
with
SE Linux, or even better if we could have functionality equivalent to PAX
in
GRSEC.  http://www.grsecurity.net/

The reason it's easier for Multics is that the hardware supports it, there
are
less bits used for storing page access in i386 and some of these things
have
to be hacked (EG by giving the code and data segments different memory
mappings such that the code segment doesn't have the stack).  It's really
ugly.  Hopefully new CPU architectures such as IA64 and IA32-64 will have
better support for such things.  I'm afraid that I can't recall the exact
details of the CPU mechanisms involved, one book that I can't recommend
highly enough is "A Guide to RISC Microprocessor Architecture" edited by
Michael Slater.  It's an old book which probably isn't in print but should
be
in any good university library.  It is really good for background knowledge
on how different CPUs do some of these things and why they do it, compare
that with any book on the i386 (there are many) and you can get some good
ideas on the relative merits of the CPUs.

Also as mentioned in the document there is a language issue, C is not the
best
language for reliable code.  If we started writing everything in Ada then
things would become much more secure.

> The parallels between then and now (27 years later) are striking. It is
> rather depressing that we are still trying to solve the same problems
they
> were trying to solve and end up reinventing the wheel.  What's worse is
> that our wheel may be rather rickety compared to theirs.

It's not surprising really.  Secure systems never entered the mainstream,
so
people with security knowledge didn't pass it on outside the security
community.  Until recently most universities didn't even have a shadow
password file on their time sharing machines!  How could they ever teach
students anything about security?!?!

Some universities are offering info-sec courses, which I expect to be
useless.
You can't have a situation where there's no semblance of security and then
just have a lecturer give some talks on security and hope for a good
result!

I've been thinking about offering some university lectures on the topic of
SE
Linux.  The idea is a lecture for all 300+ students in the course, then a
few
tutorials for a couple of classes of students that have special interest in
the area, they would then setup some SE server machines for the other
students to use.  This could fit into a regular Unix course at any Uni
(instead of boring the smarter students with tutorials on basic C coding
etc
they can do more interesting things such as learning SE Linux).

This will result in the students learning a lot about security, especially
when as part of their practical work they have to put machines online and
issue a public challenge to crack them...

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.


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



--
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: IBM's Multics paper

[Russell Coker]

On Tue, 10 Sep 2002 16:44, Trent Jaeger wrote:
> The numbers for this paper are from the policy files, policy.conf
> (pre-processed), and ss_policy (compiled) and they are for the complete
> SELinux example policy as stated in the paper.

That is more numbers than seem to be expressed in the paper.  Also as Steve 
pointed out the complete policy should be compared to the size of part of the 
file system meta-data that represents ACLs.

> I agree that the policy can be cut-down (and should be based on your
> security target), but I am not aware of any principled approaches for
> cut-down. This is the interface that administrators see at present.

My latest Debian install scripts will prompt the administrator at install time 
for the removal of unwanted policy files.  However these are still a bit 
experimental and I have not published them here yet (and I don't think I 
wrote them before the paper in question was written).

> Personally, I believe that access decisions must be made at the SELinux
> policy level, but I think that the point that Paul is trying to make is
> that  strong security guarantees must be expressed in a way that average
> system administrators can maintain (many folks on this list are well above
> average :->).  I don't think that the strong system security guarantees in
> Multics were dependent on the fine-grained policy, so this should not be
> the case for SELinux either.

How can an average sysadmin be expected to determine the details of policy?  
We are working on ways of allowing them to easily manage things at a high 
level (including policy for certain services etc), and we can also use macros 
for basic configuration of such services.  But when it comes to issues such 
as whether a daemon should have an "allow" or an "dontaudit" rule concerning 
access to the sysadm tty types it's something that none of us can agree on 
yet!  So expecting a typical sysadmin to do the right thing is probably 
expecting too much.

Securing complex systems is inherantly complex and requires a great 
understanding.

> A number of folks are awarelooking into policy management, but let me just
> update you on my recent efforts that are consistent with this discussion. I
> am doing a simple Biba integrity verification on the Apache policy relative
> the rest of the SELinux example policy (assuming trusted system and
> authentication services).  Interestingly, the only violations are: (1)
> shared files: /tmp, tmpfs_t, writeable_t; (2) a number of logging and
> system status files; (3) interactions with many services that would not be
> run with Apache (possible cut-downs).  Shared /tmp is a well-known UNIX
> problem, but its solution is independent of SELinux (although it would be a
> significant benefit).  Log files could be handled as exceptions, likely,
> although I am still looking at this.

Interesting, I look forward to when you publish this.

I think that the Apache policy needs to be changed regardless of these issues, 
it's got a number of usability issues.

> An issue that I am interested in is policy interactions with other
> services.  For example, sendmail can edit files in /etc that Apache is
> permitted to read.  This could be handled by editing the policy, but if you
> are running a highly secure Apache server do you really want to run
> sendmail too?

Use Postfix or Qmail and this problem should go away...

>  Rather than editing the policy to create your own
> specialized, possibly ad hoc policy, might it be possible to create
> "conflicting subjects" that are not permitted to run together.  Thus, the
> current SELinux policy would remain largely unchanged, but the security
> guarantees that this policy implements can be understood and verified
> against the SELinux policy.

I have been thinking of such things for usability issues.  EG Sendmail and 
Postfix policies conflicting.

> Then, the policy that the TCB depends on might include only a high-level
> Biba lattice, some verified exceptions, and some conflicting subjects.
> This would be much smaller than the entire SELinux policy (and Multics),
> but you would still have the fine-grained control that you really need to
> ensure the higher level requirements.
>
> Does this seem like a reasonable direction?  Does this interact with the
> other work on policy management for SELinux?

That sounds promising to me, but I'm not nearly as qualified as Steve et al to 
comment on this...

Also in regard to Steve's comment on the Multics paper, I didn't interpret it 
as needlessly criticising SE Linux and other similar projects.  There are 
some valid criticisms of the approach we are taking.  Designing a new OS from 
scratch will give better security.  Also I can understand that if someone 
writes an OS based on their ideas of the best way of doing things then 
naturally they will use it as an example of the way things should be done.

However I think that the mention of SE Linux did not contain enough detail for 
a fair comparison.  I think that given the nature of the paper it would make 
more sense to just discuss the concept of adding security to an existing Unix 
OS (which applies equally to Trusted Solaris, Trusted BSD, etc).  A good 
supporting point for this is that Sun is apparently going to make Trusted 
Solaris the only Solaris (I am surprised that this was not mentioned in the 
paper).  This could have been done without judging the implementation of 
Trusted Solaris, but just on the basis that the senior management of Sun have 
become convinced of some of the views expressed in that paper and backed 
their opinion with some significant investments in technology.


Russell Coker


--
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: IBM's Multics paper

[Trent Jaeger]

                                                                                                               
                                                                                                               
                                                                                                               


My lovely mail client makes it hard for me to respond to all your points in
one email, so I am going to try one at a time.

> On Tue, 10 Sep 2002 16:44, Trent Jaeger wrote:
>> The numbers for this paper are from the policy files, policy.conf
>> (pre-processed), and ss_policy (compiled) and they are for the complete
>> SELinux example policy as stated in the paper.

Russell replied:
>That is more numbers than seem to be expressed in the paper.  Also as
Steve
>pointed out the complete policy should be compared to the size of part of
the
>file system meta-data that represents ACLs.

The point Paul is trying to make is that the mandatory policy implemented
by Multics (was MLS) was represented by an simple algorithm executing in
the kernel and its integrity depended on an ACL on one file.  Therefore, it
is not necessary to include all ACLs in the analysis.

Now I agree with Paul that this is a fair comparison, but I believe that a
simple mandatory policy can be expressed for SELinux and verified against
the current TE policy to achieve the same goal.  We just haven't done it
yet.  Most of the rest of the note was about how I am starting to go about
it.

Trent.
----------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
jaegert@watson.ibm.com
(914) 784-7225, FAX (914) 784-7595




Russell Coker <russell@coker.com.au> on 09/10/2002 01:46:03 PM

Please respond to Russell Coker <russell@coker.com.au>

To:    Trent Jaeger/Watson/IBM@IBMUS
cc:    Tracy R Reed <treed@ultraviolet.org>, SE Linux
       <selinux@tycho.nsa.gov>, Paul A Karger/Watson/IBM@IBMUS
Subject:    Re: IBM's Multics paper





> I agree that the policy can be cut-down (and should be based on your
> security target), but I am not aware of any principled approaches for
> cut-down. This is the interface that administrators see at present.

My latest Debian install scripts will prompt the administrator at install
time
for the removal of unwanted policy files.  However these are still a bit
experimental and I have not published them here yet (and I don't think I
wrote them before the paper in question was written).

> Personally, I believe that access decisions must be made at the SELinux
> policy level, but I think that the point that Paul is trying to make is
> that  strong security guarantees must be expressed in a way that average
> system administrators can maintain (many folks on this list are well
above
> average :->).  I don't think that the strong system security guarantees
in
> Multics were dependent on the fine-grained policy, so this should not be
> the case for SELinux either.

How can an average sysadmin be expected to determine the details of policy?
We are working on ways of allowing them to easily manage things at a high
level (including policy for certain services etc), and we can also use
macros
for basic configuration of such services.  But when it comes to issues such
as whether a daemon should have an "allow" or an "dontaudit" rule
concerning
access to the sysadm tty types it's something that none of us can agree on
yet!  So expecting a typical sysadmin to do the right thing is probably
expecting too much.

Securing complex systems is inherantly complex and requires a great
understanding.

> A number of folks are awarelooking into policy management, but let me
just
> update you on my recent efforts that are consistent with this discussion.
I
> am doing a simple Biba integrity verification on the Apache policy
relative
> the rest of the SELinux example policy (assuming trusted system and
> authentication services).  Interestingly, the only violations are: (1)
> shared files: /tmp, tmpfs_t, writeable_t; (2) a number of logging and
> system status files; (3) interactions with many services that would not
be
> run with Apache (possible cut-downs).  Shared /tmp is a well-known UNIX
> problem, but its solution is independent of SELinux (although it would be
a
> significant benefit).  Log files could be handled as exceptions, likely,
> although I am still looking at this.

Interesting, I look forward to when you publish this.

I think that the Apache policy needs to be changed regardless of these
issues,
it's got a number of usability issues.

> An issue that I am interested in is policy interactions with other
> services.  For example, sendmail can edit files in /etc that Apache is
> permitted to read.  This could be handled by editing the policy, but if
you
> are running a highly secure Apache server do you really want to run
> sendmail too?

Use Postfix or Qmail and this problem should go away...

>  Rather than editing the policy to create your own
> specialized, possibly ad hoc policy, might it be possible to create
> "conflicting subjects" that are not permitted to run together.  Thus, the
> current SELinux policy would remain largely unchanged, but the security
> guarantees that this policy implements can be understood and verified
> against the SELinux policy.

I have been thinking of such things for usability issues.  EG Sendmail and
Postfix policies conflicting.

> Then, the policy that the TCB depends on might include only a high-level
> Biba lattice, some verified exceptions, and some conflicting subjects.
> This would be much smaller than the entire SELinux policy (and Multics),
> but you would still have the fine-grained control that you really need to
> ensure the higher level requirements.
>
> Does this seem like a reasonable direction?  Does this interact with the
> other work on policy management for SELinux?

That sounds promising to me, but I'm not nearly as qualified as Steve et al
to
comment on this...

Also in regard to Steve's comment on the Multics paper, I didn't interpret
it
as needlessly criticising SE Linux and other similar projects.  There are
some valid criticisms of the approach we are taking.  Designing a new OS
from
scratch will give better security.  Also I can understand that if someone
writes an OS based on their ideas of the best way of doing things then
naturally they will use it as an example of the way things should be done.

However I think that the mention of SE Linux did not contain enough detail
for
a fair comparison.  I think that given the nature of the paper it would
make
more sense to just discuss the concept of adding security to an existing
Unix
OS (which applies equally to Trusted Solaris, Trusted BSD, etc).  A good
supporting point for this is that Sun is apparently going to make Trusted
Solaris the only Solaris (I am surprised that this was not mentioned in the
paper).  This could have been done without judging the implementation of
Trusted Solaris, but just on the basis that the senior management of Sun
have
become convinced of some of the views expressed in that paper and backed
their opinion with some significant investments in technology.


Russell Coker




--
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: IBM's Multics paper

[Trent Jaeger]

                                                                                                               
                                                                                                               
                                                                                                               


Another comment on Russell's reply.

Russell replied:
>How can an average sysadmin be expected to determine the details of
policy?
>We are working on ways of allowing them to easily manage things at a high
>level (including policy for certain services etc), and we can also use
macros
>for basic configuration of such services.  But when it comes to issues
such
>as whether a daemon should have an "allow" or an "dontaudit" rule
concerning
>access to the sysadm tty types it's something that none of us can agree on
>yet!  So expecting a typical sysadmin to do the right thing is probably
>expecting too much.

>Securing complex systems is inherantly complex and requires a great
>understanding.

I think that maybe we are talking about different things.

My definition of 'Doing the right thing' for a sysadmin is different.
Sysadmins must be able to say that their systems are secure according to
their criteria.  These criteria must be simple enough to be understood by
sysadmins.  Therefore, these criteria are not the individual permissions of
individual daemons, which I agree is too much.    However, the
implementation of these criteria will likely require changing the SELinux
example policy.  So, sysadmins need an approach by which they can express
and maintain their criteria and ensure that the SELinux policy they use
meets those criteria.

I envision that sysadmins have a simpler expression for their security
criteria, have tools to test them reliably, and then they can work with the
per daemon policy experts to make refinements as necessary.

If sysadmins cannot configure SELinux systems correctly, we have problems.
The rest of my note discussed where I am going with this, but I expect that
others have ideas as well.

Trent.
----------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
jaegert@watson.ibm.com
(914) 784-7225, FAX (914) 784-7595




--
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: IBM's Multics paper

[Trent Jaeger]

                                                                                                               
                                                                                                               
                                                                                                               


Last time for this note.

Russell replied:
>That sounds promising to me, but I'm not nearly as qualified as Steve et
al to
>comment on this...

>Also in regard to Steve's comment on the Multics paper, I didn't interpret
it
>as needlessly criticising SE Linux and other similar projects.  There are
>some valid criticisms of the approach we are taking.  Designing a new OS
from
>scratch will give better security.  Also I can understand that if someone
>writes an OS based on their ideas of the best way of doing things then
>naturally they will use it as an example of the way things should be done.

>However I think that the mention of SE Linux did not contain enough detail
for
>a fair comparison.  I think that given the nature of the paper it would
make
>more sense to just discuss the concept of adding security to an existing
Unix
>OS (which applies equally to Trusted Solaris, Trusted BSD, etc).  A good
>supporting point for this is that Sun is apparently going to make Trusted
>Solaris the only Solaris (I am surprised that this was not mentioned in
the
>paper).  This could have been done without judging the implementation of
>Trusted Solaris, but just on the basis that the senior management of Sun
have
>become convinced of some of the views expressed in that paper and backed
>their opinion with some significant investments in technology.

Russell, thanks for your comments.  I should have a quite preliminary
version of my paper in the near future.

I think that the only point of the paper that we can take away (since we
are not going to build a new OS from scratch on this list), is that the MAC
policy of SELinux is much larger than MAC policy of Multics according to
Paul.  It provides greater flexibility, yes, but sysadmins must be able to
verify that their mandatory security criteria are met by the MAC SELinux
policy.

BTW -- the number in the paper is the size of ss_policy for the entire
SELinux example policy.

Trent.
----------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
jaegert@watson.ibm.com
(914) 784-7225, FAX (914) 784-7595


--
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: IBM's Multics paper

[Russell Coker]

On Tue, 10 Sep 2002 20:36, Trent Jaeger wrote:
> >Securing complex systems is inherantly complex and requires a great
> >understanding.
>
> I think that maybe we are talking about different things.
>
> My definition of 'Doing the right thing' for a sysadmin is different.
> Sysadmins must be able to say that their systems are secure according to
> their criteria.  These criteria must be simple enough to be understood by
> sysadmins.  Therefore, these criteria are not the individual permissions of
> individual daemons, which I agree is too much.    However, the
> implementation of these criteria will likely require changing the SELinux
> example policy.  So, sysadmins need an approach by which they can express
> and maintain their criteria and ensure that the SELinux policy they use
> meets those criteria.

That sounds like a nice ideal, however I doubt that it is possible.

Based on past experience I believe that the average sysadmin is unable to 
manage basic Unix permissions, or have a good understanding of how to do 
their job properly.

The belief that "when you have RAID you don't need" backups is reasonably 
common as is the belief that TCP wrappers are a good substitute for a 
firewall.  I only recall meeting two people in the course of work (IE people 
who I did not know previously through the Linux community etc) who really 
believe in testing things.  In all the biggest projects I have worked on (big 
in terms of large sums of money spent on them, large number of people 
involved in development, and in terms of visibility by customers if they 
fail) I have been explicitely prohibited from doing any serious testing 
because "it might be too risky to test power outages etc", so of course when 
you go live without any testing it's not considered a risk.  :(

Complex tasks require intelligent skilled people to complete them.  I doubt 
that you can make SE Linux management easy enough for the typical sysadmin, 
but I look forward to seeing what you can develop.

Next time we meet I'll have to recite my list of Unix horror stories for you.  
It includes examples of vendors (hardware and software), consultants, 
sysadmins, managers, and HR people and how they give the impression of 
conspiring to derail projects that might otherwise be successful.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.


--
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: IBM's Multics paper

[Paweł Krawczyk]

On Tue, Sep 10, 2002 at 11:19:12AM +0200, Russell Coker wrote:

> The recent OpenWall patches include trampoline support.  I've run it on some 
> production servers and have not been able to find any problems caused by it.
> Hopefully at some time in the near future we'll be able to combine this with 
> SE Linux, or even better if we could have functionality equivalent to PAX in 
> GRSEC.  http://www.grsecurity.net/

Actually, as you touched that topic, for a quite long time I was
thinking how good would it be to have combined functionality of
GRsecurity and SElinux. GRsecurity has many general system hardening
functions (including Openwall and PAX for non-executable stack)
and a MAC/ACL system. However, the latter seems to be much more complete
and mature in SElinux.

As for the Openwall and PAX, there's no good answer for which system
to use, as PAX seems to be more actively developed but has bigger
performance overhead (up to 10% AFAIK) than OW. Currently I'm using
OW with several PAX features (address space randomizing) in production
embedded systems and it works well.

Also, it might be interesting for all of you - one such device (Linux
based) is being now evaluated for E2 level by ABW (Polish NSA equivalent).

-- 
Paweł Krawczyk, Kraków, Poland  http://echelon.pl/kravietz/
crypto: http://ipsec.pl/
horses: http://kabardians.com/

--
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: IBM's Multics paper

[Russell Coker]

On Wed, 11 Sep 2002 08:53, Paweł Krawczyk wrote:
> As for the Openwall and PAX, there's no good answer for which system
> to use, as PAX seems to be more actively developed but has bigger
> performance overhead (up to 10% AFAIK) than OW. Currently I'm using
> OW with several PAX features (address space randomizing) in production
> embedded systems and it works well.

Ideally you would be presented with a choice of what level of stack/memory 
protection to have, varying from the basic stack-smashing protection in 
OpenWall to the full PAX support.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.


--
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: IBM's Multics paper (let's not confuse assurance and mandatory security)

[Frank Mayer]

I for one would like to thank Tracy for bringing this topic to the list;
it's is a central topic and should not shunted off this list.

I suggest that readers try to separate the ideas of "mandatory security"
mechanisms and "assurance" of correctness and completeness.   To their
credit, I do not believe that any of the SE Linux papers, and I
personally know that none of the SE Linux developers (despite Steve's
comments earlier), have asserted that SE Linux was a high-assurance OS
implementation. Perhaps the one fault with Roger and Paul's paper is
that it might leave the reader with that impression.  I believe SE Linux
was offered as an open-source implementation of DTE (and optionally MLS)
mandatory mechanisms, and was not offered as an example of a
high-assurance OS implementation.

If the reader is interested in making Linux/Unix easier to "harden" and
strengthen, then I endorse exploration of SE Linux (as we are doing).
Type-enforcement mechanisms are a good foundation for strong security,
and while there is great complexity in security policies, continued work
towards managing security policies will help us gain some control over
that complexity.  I do believe that a SE Linux, once complete and
reasonably tested and analyzed, provides a much better platform for
hardened applications than vanilla Linux/Unix.

However, if the reader is interested in high-assurance OSes, then I
strongly recommend reading Roger and Paul's papers (and all those they
reference!).  Don't fool yourself into believing that the addition of
mandatory security equates to high-assurance (or even "medium"
assurance).  As they aptly point out, Multics didn't even achieve the
definition of high-assurance, and its fundamental protection mechanisms
far exceed anything in Unix-like kernels.  I will even say that the one
Unix-like OS that also achieved a "medium" assurance B2 rating like
Multics (Trusted XENIX, for which I'll admit significant involvement),
paled in comparison to Multics protection robustness, and in many
people's opinion, lowered the bar of what is "medium" assurance.  And
neither of these were high-assurance.  Even some of the attempts to use
mainstream micro-kernels as baselines for high assurance (e.g., TMach,
which I'll also admit significant participation, and later DTMach, a
direct antecedent to SE Linux I believe), did not in my opinion approach
levels of assurance beyond Multics, despite claims at the time.

So I would like to offer two points of encouragement:

1. For all those Linux/Unix folks trying to make their system more
security robust, let's keep working on SE Linux and make it better.  The
type-enforcement mechanisms gives me great hope that we can
significantly increase the security strength of a large percentage of
computer systems in the near future.

2. For all those trying to solve extremely sensitive data sharing
problems (e.g., multiple levels of classified national secrets), then go
into SE Linux with open eyes.  It certainly has more potential than
vanilla Unix/Linux, or even the compartmented-mode workstations you may
be used to, but it is not high, or even medium assurance, and not likely
to have a chance of even medium robustness any time soon (if at all).
So at a minimum, understand these assurance weaknesses and recognize the
residual risks and take appropriate counter-measures.  And perhaps even
consider re-starting some high-assurance research if we can convince
ourselves of a chance of success this time.

Frank Mayer


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