From john.weeks at sun.com Tue Mar 18 14:08:45 2008 From: john.weeks at sun.com (John Weeks) Date: Tue, 18 Mar 2008 14:08:45 -0700 Subject: [fmac-discuss] Status Update Message-ID: <47E02F5D.9010508@sun.com> Hello FMAC Community, Is has been a couple of weeks since we posted the project page and I thought it would be a good time for a brief status update. First of all, I would like to thank the community for all the positive responses about the project. We really need to work together to achieve the goals we outlined in the project proposal. Not only can our progress be rewarding to those participating in the project, but it could have a positive impact on the world as well as we work together to advance security technology. We are going through the steps required to accept a code contribution for the base Flask/TE implementation. After we bring it in, it will be integrated into a project source repository based on OS/Net (ON) build 85 or later and this will be the base for our community prototyping and research. Over time, we will synchronize with current versions of ON to track current development activities. This will consume resources, but I believe it is a necessity :-) As for design ideas and contributions, it's all going to happen here. If you have something you would like to contribute, please let us know. As we start to refine our technical directions, it will be posted to this discuss alias. For those of you that would like to read up more on Flask/TE, here are pointers to papers on the topic: The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments: http://www.nsa.gov/selinux/papers/inevit-abs.cfm The Flask Security Architecture: System Support for Diverse Security Policies: http://www.nsa.gov/selinux/papers/flask-abs.cfm More updates to follow as progress is made. Regards, John Weeks From john.weeks at sun.com Wed Mar 26 20:07:01 2008 From: john.weeks at sun.com (John Weeks) Date: Wed, 26 Mar 2008 20:07:01 -0700 Subject: [fmac-discuss] FMAC System Call Implementation Message-ID: <47EB0F55.9090401@sun.com> Hi, As I'm integrating the Flask/TE code into an ON tree, I need to implement several FMAC specific system calls. We could either take one of the few remaining unassigned system call numbers (I think it's less than 6), or add additional subcodes to the existing Solaris Trusted Extensions labelsys() implementation. My preference is to help save the few system call numbers that are left and just extend labelsys(). My rational: 1. labelsys() already handles 5 arguments 2. labelsys() return on int (this should be find for SID's) 3. labelsys() is only using 6 subcodes 4. FMAC is security related labelsys() subcodes 1-6 (usr/src/uts/common/sys/tsol/tsyscall.h) are currently defined. We could bump up the FMAC calls to start at 32 which will allow ample room for growth for Solaris Trusted Extensions (1-31). Comments? -John From Glenn.Faden at Sun.COM Wed Mar 26 22:10:58 2008 From: Glenn.Faden at Sun.COM (Glenn Faden) Date: Wed, 26 Mar 2008 22:10:58 -0700 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <47EB0F55.9090401@sun.com> References: <47EB0F55.9090401@sun.com> Message-ID: <47EB2C62.9070103@sun.com> Adding new system calls to Trusted Extensions seems best to me. I don't know why you would need to leave a gap in the table. Just take the next available number. --Glenn John Weeks wrote: > Hi, > > As I'm integrating the Flask/TE code into an ON tree, I need to implement > several FMAC specific system calls. We could either take one of the few > remaining unassigned system call numbers (I think it's less than 6), or add > additional subcodes to the existing Solaris Trusted Extensions labelsys() > implementation. > > My preference is to help save the few system call numbers that are left and just > extend labelsys(). My rational: > > 1. labelsys() already handles 5 arguments > 2. labelsys() return on int (this should be find for SID's) > 3. labelsys() is only using 6 subcodes > 4. FMAC is security related > > labelsys() subcodes 1-6 (usr/src/uts/common/sys/tsol/tsyscall.h) are currently > defined. We could bump up the FMAC calls to start at 32 which will allow ample > room for growth for Solaris Trusted Extensions (1-31). > > Comments? > > -John > > > _______________________________________________ > fmac-discuss mailing list > fmac-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/fmac-discuss > From john.weeks at sun.com Wed Mar 26 22:53:32 2008 From: john.weeks at sun.com (John Weeks) Date: Wed, 26 Mar 2008 22:53:32 -0700 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <47EB2C62.9070103@sun.com> References: <47EB0F55.9090401@sun.com> <47EB2C62.9070103@sun.com> Message-ID: <47EB365C.3010003@sun.com> Glenn Faden wrote: > Adding new system calls to Trusted Extensions seems best to me. I don't > know why you would need to leave a gap in the table. Just take the next > available number. > > --Glenn > > John Weeks wrote: >> Hi, >> >> As I'm integrating the Flask/TE code into an ON tree, I need to implement >> several FMAC specific system calls. We could either take one of the few >> remaining unassigned system call numbers (I think it's less than 6), or add >> additional subcodes to the existing Solaris Trusted Extensions labelsys() >> implementation. >> >> My preference is to help save the few system call numbers that are left and just >> extend labelsys(). My rational: >> >> 1. labelsys() already handles 5 arguments >> 2. labelsys() return on int (this should be find for SID's) >> 3. labelsys() is only using 6 subcodes >> 4. FMAC is security related >> >> labelsys() subcodes 1-6 (usr/src/uts/common/sys/tsol/tsyscall.h) are currently >> defined. We could bump up the FMAC calls to start at 32 which will allow ample >> room for growth for Solaris Trusted Extensions (1-31). >> >> Comments? >> >> -John >> >> >> _______________________________________________ >> fmac-discuss mailing list >> fmac-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/fmac-discuss >> > > _______________________________________________ > fmac-discuss mailing list > fmac-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/fmac-discuss Since we'll be working in a project specific Mercurial repository cloned from onnv, leaving the gap prevents collisions if somebody adds another labelsys() subcode (e.g., 7) to onnv before we merge upstream. When we do an upstream merge, starting with the next available labelsys() subcode would be desirable. -John From Casper.Dik at Sun.COM Thu Mar 27 02:24:28 2008 From: Casper.Dik at Sun.COM (Casper.Dik at Sun.COM) Date: Thu, 27 Mar 2008 10:24:28 +0100 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <47EB2C62.9070103@sun.com> References: <47EB0F55.9090401@sun.com> <47EB2C62.9070103@sun.com> Message-ID: <200803270924.m2R9OSi0002592@dm-holland-01.uk.sun.com> >Adding new system calls to Trusted Extensions seems best to me. I don't >know why you would need to leave a gap in the table. Just take the next >available number. +1 (Though I don't think there's a hard limit to the number of entries in the system call table or that only 6 slots are available) Casper From William.Young at Sun.COM Thu Mar 27 10:14:59 2008 From: William.Young at Sun.COM (William Young) Date: Thu, 27 Mar 2008 13:14:59 -0400 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <47EB365C.3010003@sun.com> References: <47EB0F55.9090401@sun.com> <47EB2C62.9070103@sun.com> <47EB365C.3010003@sun.com> Message-ID: <47EBD613.7040700@sun.com> John Weeks wrote: > > Since we'll be working in a project specific Mercurial repository cloned from > onnv, leaving the gap prevents collisions if somebody adds another labelsys() > subcode (e.g., 7) to onnv before we merge upstream. When we do an upstream > merge, starting with the next available labelsys() subcode would be desirable. This sounds good to me. TX deciding to add another TNR database before FMAC's integration is not out of the scope of possibilities. -Will From sds at tycho.nsa.gov Fri Mar 28 06:21:37 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 28 Mar 2008 09:21:37 -0400 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <47EB0F55.9090401@sun.com> References: <47EB0F55.9090401@sun.com> Message-ID: <1206710497.3302.431.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-03-26 at 20:07 -0700, John Weeks wrote: > Hi, > > As I'm integrating the Flask/TE code into an ON tree, I need to implement > several FMAC specific system calls. We could either take one of the few > remaining unassigned system call numbers (I think it's less than 6), or add > additional subcodes to the existing Solaris Trusted Extensions labelsys() > implementation. > > My preference is to help save the few system call numbers that are left and just > extend labelsys(). My rational: > > 1. labelsys() already handles 5 arguments > 2. labelsys() return on int (this should be find for SID's) I wouldn't recommend returning SIDs in that manner. First, there is the question of whether you want to expose kernel SIDs to userspace at all (not done by the Linux implementation of Flask/TE today - we can talk about that as a separate topic if you like; Linux only exposes security contexts to userspace and there are separate userspace SID mappings for policy-enforcing applications like Xorg). Even if you do export kernel SIDs to userspace, they should be passed by argument and as unsigned integers rather than overloading the return status for them. > 3. labelsys() is only using 6 subcodes > 4. FMAC is security related > > labelsys() subcodes 1-6 (usr/src/uts/common/sys/tsol/tsyscall.h) are currently > defined. We could bump up the FMAC calls to start at 32 which will allow ample > room for growth for Solaris Trusted Extensions (1-31). > > Comments? Only concern I have with using labelsys() in this manner is that normally labelsys() would only get used if someone were using trusted extensions, right? Whereas people may very well want to use FMAC Flask/TE functionality in situations where trusted extensions is not required (most common use of SELinux today is to harden servers by confining services running on them). So if you use labelsys() in this manner, it has to always be available to applications for use even if trusted extensions is not enabled. Does that present any problems? -- Stephen Smalley National Security Agency From Glenn.Faden at Sun.COM Fri Mar 28 07:13:50 2008 From: Glenn.Faden at Sun.COM (Glenn Faden) Date: Fri, 28 Mar 2008 07:13:50 -0700 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <1206710497.3302.431.camel@moss-spartans.epoch.ncsc.mil> References: <47EB0F55.9090401@sun.com> <1206710497.3302.431.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <47ECFD1E.1050507@sun.com> Stephen Smalley wrote: > On Wed, 2008-03-26 at 20:07 -0700, John Weeks wrote: > > >> labelsys() subcodes 1-6 (usr/src/uts/common/sys/tsol/tsyscall.h) are currently >> defined. We could bump up the FMAC calls to start at 32 which will allow ample >> room for growth for Solaris Trusted Extensions (1-31). >> >> Comments? >> > > Only concern I have with using labelsys() in this manner is that > normally labelsys() would only get used if someone were using trusted > extensions, right? Whereas people may very well want to use FMAC > Flask/TE functionality in situations where trusted extensions is not > required (most common use of SELinux today is to harden servers by > confining services running on them). So if you use labelsys() in this > manner, it has to always be available to applications for use even if > trusted extensions is not enabled. Does that present any problems? > The labelsys code is always present in the kernel, regardless of whether Trusted Extensions is enabled. So it is OK for FMAC to use it for new syscall vectors. --Glenn From john.weeks at sun.com Fri Mar 28 13:34:09 2008 From: john.weeks at sun.com (John Weeks) Date: Fri, 28 Mar 2008 13:34:09 -0700 Subject: [fmac-discuss] FMAC System Call Implementation In-Reply-To: <1206710497.3302.431.camel@moss-spartans.epoch.ncsc.mil> References: <47EB0F55.9090401@sun.com> <1206710497.3302.431.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <47ED5641.9080303@sun.com> Stephen Smalley wrote: > On Wed, 2008-03-26 at 20:07 -0700, John Weeks wrote: >> Hi, >> >> As I'm integrating the Flask/TE code into an ON tree, I need to implement >> several FMAC specific system calls. We could either take one of the few >> remaining unassigned system call numbers (I think it's less than 6), or add >> additional subcodes to the existing Solaris Trusted Extensions labelsys() >> implementation. >> >> My preference is to help save the few system call numbers that are left and just >> extend labelsys(). My rational: >> >> 1. labelsys() already handles 5 arguments >> 2. labelsys() return on int (this should be find for SID's) > > I wouldn't recommend returning SIDs in that manner. First, there is the > question of whether you want to expose kernel SIDs to userspace at all > (not done by the Linux implementation of Flask/TE today - we can talk > about that as a separate topic if you like; Linux only exposes security > contexts to userspace and there are separate userspace SID mappings for > policy-enforcing applications like Xorg). Even if you do export kernel > SIDs to userspace, they should be passed by argument and as unsigned > integers rather than overloading the return status for them. Oops, my bad. I must have been thing kernel interface at the time ;-) > >> 3. labelsys() is only using 6 subcodes >> 4. FMAC is security related >> >> labelsys() subcodes 1-6 (usr/src/uts/common/sys/tsol/tsyscall.h) are currently >> defined. We could bump up the FMAC calls to start at 32 which will allow ample >> room for growth for Solaris Trusted Extensions (1-31). >> >> Comments? > > Only concern I have with using labelsys() in this manner is that > normally labelsys() would only get used if someone were using trusted > extensions, right? Whereas people may very well want to use FMAC > Flask/TE functionality in situations where trusted extensions is not > required (most common use of SELinux today is to harden servers by > confining services running on them). So if you use labelsys() in this > manner, it has to always be available to applications for use even if > trusted extensions is not enabled. Does that present any problems? >