* SELinux project @ 2003-09-13 9:45 kamal 2003-09-15 12:42 ` Stephen Smalley 0 siblings, 1 reply; 6+ messages in thread From: kamal @ 2003-09-13 9:45 UTC (permalink / raw) To: SELinux 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux project 2003-09-13 9:45 SELinux project kamal @ 2003-09-15 12:42 ` Stephen Smalley 2003-09-15 16:07 ` Frank Mayer 2003-09-15 19:34 ` Trent Jaeger 0 siblings, 2 replies; 6+ messages in thread From: Stephen Smalley @ 2003-09-15 12:42 UTC (permalink / raw) To: kamal; +Cc: SELinux, Trent Jaeger 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: SELinux project 2003-09-15 12:42 ` Stephen Smalley @ 2003-09-15 16:07 ` Frank Mayer 2003-09-15 19:34 ` Trent Jaeger 1 sibling, 0 replies; 6+ messages in thread From: Frank Mayer @ 2003-09-15 16:07 UTC (permalink / raw) To: 'Stephen Smalley', 'kamal' Cc: SELinux, 'Trent Jaeger' > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux project 2003-09-15 12:42 ` Stephen Smalley 2003-09-15 16:07 ` Frank Mayer @ 2003-09-15 19:34 ` Trent Jaeger 2003-09-15 21:08 ` kamal 1 sibling, 1 reply; 6+ messages in thread From: Trent Jaeger @ 2003-09-15 19:34 UTC (permalink / raw) To: Stephen Smalley; +Cc: kamal, owner-selinux, SELinux [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux project 2003-09-15 19:34 ` Trent Jaeger @ 2003-09-15 21:08 ` kamal 2003-09-15 21:31 ` Trent Jaeger 0 siblings, 1 reply; 6+ messages in thread From: kamal @ 2003-09-15 21:08 UTC (permalink / raw) To: Trent Jaeger; +Cc: SELinux 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux project 2003-09-15 21:08 ` kamal @ 2003-09-15 21:31 ` Trent Jaeger 0 siblings, 0 replies; 6+ messages in thread From: Trent Jaeger @ 2003-09-15 21:31 UTC (permalink / raw) To: kamal; +Cc: SELinux [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-09-15 21:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-09-13 9:45 SELinux project kamal 2003-09-15 12:42 ` Stephen Smalley 2003-09-15 16:07 ` Frank Mayer 2003-09-15 19:34 ` Trent Jaeger 2003-09-15 21:08 ` kamal 2003-09-15 21:31 ` Trent Jaeger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.