SELinux project

SELinux project

[kamal]

We are two final year under-graduate students in Computer Science. We 
are doing our year long project in the field of Linux security. We have 
studied SELinux and various access control models.  As a first step, we 
are thinking of implementing Biba integrity model in SELinux, along the 
lines of MLS implementation. Because we are new in the field, we want to 
have your views on how useful it will be, and maybe some guidelines too.
Thanks.


--
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: SELinux project

[Stephen Smalley]

On Sat, 2003-09-13 at 05:45, kamal wrote:
> We are two final year under-graduate students in Computer Science. We 
> are doing our year long project in the field of Linux security. We have 
> studied SELinux and various access control models.  As a first step, we 
> are thinking of implementing Biba integrity model in SELinux, along the 
> lines of MLS implementation. Because we are new in the field, we want to 
> have your views on how useful it will be, and maybe some guidelines too.
> Thanks.

Since TE provides a more general integrity mechanism, I don't see it as
overly useful to implement a Biba integrity model for SELinux.  It is
likely more useful to work on policy analysis tools for the TE
configuration that can check it against specified higher level policy
constraints, including Biba-style constraints, and identify violations
of those constraints.  Trent Jaeger has done some work in this area, so
I've cc'd him.  See http://www.usenix.org/events/sec03/tech/jaeger.html
for a published paper on his work.

Rather than building a new tool from scratch, you might want to consider
building extensions to existing open source tools, such as the Tresys
tools, available from http://www.tresys.com/selinux.  I think that they
are working on improved information flow analysis capabilities, so that
would help in such work.
  
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: SELinux project

[Frank Mayer]

> Rather than
> building a new tool from scratch, you might want to consider
> building extensions to existing open source tools, such as the Tresys
> tools, available from http://www.tresys.com/selinux.  I think that
> they are working on improved information flow analysis
> capabilities, so that
> would help in such work.
> 
> --
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency

We'd welcome contributions.  As Steve mentioned, we're about to release a new
version of our analysis tool that will start to address the overt information
flow problem (which is quite challenging in such a rich policy language).  One
of the directions we working toward is tools that provide ability to help
develop policies that implement desire security policies that can be
demonstrated correct (informally) in support of certifications and assessments.

Frank


--
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: SELinux project

[Trent Jaeger]

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

Yes, I agree with Stephen that implementing the Biba integrity policy on 
SELinux would not be very practical. 

The analysis in our paper demonstrates that many trusted tasks in UNIX 
systems use low integrity data in ways that would violate Biba.  However, 
many of the cases should not compromise security (the system depends on 
high integrity tasks properly using this data), and the others are best 
addressed by outright denial or policy changes.  But, they must be 
examined on a case-by-case basis (we cannot simply assume that a reader is 
trusted to handle all low integrity data).

Thus, I do not think that you could implement a Biba policy that would 
support any interesting UNIX system.

The question we are trying to answer now is: how can we present Biba 
integrity violations and related info to the admin, such that they can 
effectively manage Biba violations?  For example, our Gokyo tool can: (1) 
identify Biba violations in an SELinux policy; (2) enable the admin to 
scan the sources of the violations (policy assignments); and (3) express 
resolutions to the violations (albeit at a low level).  I am not happy 
with the usability of such an approach, yet. 

As far as an undergrad project related to SELinux policy and Biba, you may 
want to consider looking at the causes of the Biba integrity violations in 
an SELinux policy (a list is in our paper) and their proposed resolutions 
(also in the paper).  Some classes of violations using network data and 
fifos have not been examined in depth.  For some trusted applications, how 
is the low integrity data used?  Can you prove that it will not be a 
problem?  Do these applications need to be modified to ensure that the low 
data usage is safe?  Do the applications still run after modification?

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






Stephen Smalley <sds@epoch.ncsc.mil>
Sent by: owner-selinux@tycho.nsa.gov
09/15/2003 08:42 AM
 
        To:     kamal <kamalnee@iitk.ac.in>
        cc:     SELinux@tycho.nsa.gov, Trent Jaeger/Watson/IBM@IBMUS
        Subject:        Re: SELinux project


On Sat, 2003-09-13 at 05:45, kamal wrote:
> We are two final year under-graduate students in Computer Science. We
> are doing our year long project in the field of Linux security. We have
> studied SELinux and various access control models.  As a first step, we
> are thinking of implementing Biba integrity model in SELinux, along the
> lines of MLS implementation. Because we are new in the field, we want to
> have your views on how useful it will be, and maybe some guidelines too.
> Thanks.

Since TE provides a more general integrity mechanism, I don't see it as
overly useful to implement a Biba integrity model for SELinux.  It is
likely more useful to work on policy analysis tools for the TE
configuration that can check it against specified higher level policy
constraints, including Biba-style constraints, and identify violations
of those constraints.  Trent Jaeger has done some work in this area, so
I've cc'd him.  See http://www.usenix.org/events/sec03/tech/jaeger.html
for a published paper on his work.

Rather than building a new tool from scratch, you might want to consider
building extensions to existing open source tools, such as the Tresys
tools, available from http://www.tresys.com/selinux.  I think that they
are working on improved information flow analysis capabilities, so that
would help in such work.

--
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

[-- Attachment #2: Type: text/html, Size: 5192 bytes --]

Re: SELinux project

[kamal]

Thanks a lot for the suggestions!
Our interest related to integrity is slightly different. SELinux seems 
to take good care of the security of the system. But consider a military 
environment and think about actual users. A high ranking officer has got 
lots of documents from juniors and his boss, some of them possibly 
copied from their directories, and some sent through email. Now all the 
documents should not appear same to him, there should be an easy 
classification based on integrity and confidentiality of a document. He 
should not unknowingly be able to move information in a way that 
violates Biba and BLP constraints. We also want to see how digital 
signatures and encryption can be tightly and transparently integrated 
with this, e.g. in assigning integrity level to an incoming email 
attachment.
Another thing in our mind is decentralization of users' 
confidentiality/integrity levels. I mean putting this policy on some 
central server. After all, users don't belong to a computer, they belong 
to an organization. Decentralizing parts of general TE policy seems more 
difficult, levels seem easier to handle.
I wonder whether all this makes sense. Does it?


--
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: SELinux project

[Trent Jaeger]

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

So you have the following reqs:

(1) Some form of Biba/BLP policy  -- SELinux can provide support, but it 
depends on the details of your policy. SELinux does not directly support 
Biba, so you'd probably have to think in TE model and map (or verify as we 
do). 
(2) Use signatures to establish labels and encryption for secrecy -- this 
is mostly outside SELinux, so it should be doable
(3) Multi-domain policies -- not supported explicitly in SELinux.  If you 
have administrative control over the computers in question this could be 
done, but it is an open task.

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





kamal <kamalnee@iitk.ac.in>
09/15/2003 05:08 PM
 
        To:     Trent Jaeger/Watson/IBM@IBMUS
        cc:     SELinux@tycho.nsa.gov
        Subject:        Re: SELinux project


Thanks a lot for the suggestions!
Our interest related to integrity is slightly different. SELinux seems
to take good care of the security of the system. But consider a military
environment and think about actual users. A high ranking officer has got
lots of documents from juniors and his boss, some of them possibly
copied from their directories, and some sent through email. Now all the
documents should not appear same to him, there should be an easy
classification based on integrity and confidentiality of a document. He
should not unknowingly be able to move information in a way that
violates Biba and BLP constraints. We also want to see how digital
signatures and encryption can be tightly and transparently integrated
with this, e.g. in assigning integrity level to an incoming email
attachment.
Another thing in our mind is decentralization of users'
confidentiality/integrity levels. I mean putting this policy on some
central server. After all, users don't belong to a computer, they belong
to an organization. Decentralizing parts of general TE policy seems more
difficult, levels seem easier to handle.
I wonder whether all this makes sense. Does it?


[-- Attachment #2: Type: text/html, Size: 2996 bytes --]