From mboxrd@z Thu Jan 1 00:00:00 1970 From: jobol@nonadev.net (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Tue, 27 Jun 2017 12:51:38 +0200 Subject: The secmark "one user" policy In-Reply-To: References: <2fbe01aa-8f9b-37f0-f79a-e34dcd1d0705@schaufler-ca.com> <118c3a45-8587-5cb9-fcd8-5cd8ca63a779@schaufler-ca.com> <734c4437-866b-ef10-0e1c-14b8d55dd528@schaufler-ca.com> <20170626095428.4c27fc71@d-jobol.iot.bzh> Message-ID: <20170627125138.6601452b@d-jobol.iot.bzh> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Mon, 26 Jun 2017 08:10:44 -0700 Casey Schaufler wrote: > On 6/26/2017 12:54 AM, Jos? Bollo wrote: > > On Sun, 25 Jun 2017 11:05:24 -0700 > > Casey Schaufler wrote: > > > >> On 6/25/2017 2:41 AM, James Morris wrote: > >>> On Fri, 23 Jun 2017, Casey Schaufler wrote: > >>> > >>>> On 6/22/2017 8:12 PM, James Morris wrote: > >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote: > >>>>> > >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is > >>>>>> not the goal so much as the test case. MAC was the coolest > >>>>>> possible technology in 1990. We've implemented it. I don't see > >>>>>> anyone doing a new MAC implementation. I *do* see security > >>>>>> modules that implement other security models in the pipeline. > >>>>>> Some of these need to maintain state, which means using > >>>>>> security blobs in the LSM architecture. Some of these models > >>>>>> will want to use secmarks to implement socket based > >>>>>> controls. > >>>>> Where are these LSMs and where are the discussions about their > >>>>> LSM API needs? > >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, > >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. > >>>> have all been discussed on the LSM list in the past two > >>>> years. > >>> Which of these need to use secmarks to implement socket > >>> controls? > >> PTAGS doesn't, but will need to do so to be complete. > > Hello Casey, > > > > The very sleepy PTAGS is suddently awaken (at least one ear :^). > > > > In my mind, PTAGS is dealing with processes. When packets are > > filtered, the only revelent info is the emitter process. At the > > moment, I don't see valuable situation where mediation isn't > > explicit thus faking origin isn't needed. > > > > So I would really like to understand your vision here. What do I > > miss? > > My thought is that getting the tags of the process on the other > end of a network connection seems like a valuable facility. I can see 3 objections: (1) secmark isn't really interesting for transmitting hierachical strings; (2) maintaining 2 or more remotes in a coherent state implies more than implicit assumptions; (3) never trust the network. Best regards I sign Jos? but is it me or just someone in the middle that wrote it? > > > > > Best regards > > Jos? > > > > PS. I reworked the TUI (Task Unic Id) and have something valuable > > now. I haven't submitted it because I wanted to include a kind of > > FS library to provide /proc like features. But it is a nightmare to > > find a minute to work on this challenging part. I should really > > abandon that and work on TUI + PTAGS y basta. > > > >> -- > >> To unsubscribe from this list: send the line "unsubscribe > >> linux-security-module" in the body of a message to > >> majordomo at vger.kernel.org More majordomo info at > >> http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-security-module" in the body of a message to > > majordomo at vger.kernel.org More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in the body of a message to > majordomo at vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html