The secmark "one user" policy

[José Bollo]

On Mon, 26 Jun 2017 08:10:44 -0700
Casey Schaufler <casey at schaufler-ca.com> wrote:

> On 6/26/2017 12:54 AM, José Bollo wrote:
> > On Sun, 25 Jun 2017 11:05:24 -0700
> > Casey Schaufler <casey at schaufler-ca.com> 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