Thanks for the responses and blog posts, nice to get a little bit more history and ideology behind the design.
I guess I really meant creation time vs open. Taking into consideration the above points, labeling at creation time of the object (build time), and then having some mechanism for fixing up labels post build (some type of relabeld), without going through the OTA mechanism, would be quite interesting to start working on, see how viable it is. I started working on a from scratch daemon at Samsung, but only had about 2 days into it, so it didn't get that far. Bill On Tue, Aug 20, 2013 at 11:14 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 08/20/2013 02:03 PM, Joshua Brindle wrote: > > William Roberts wrote: > >> Picking up on this: > >> > >> > Yeah I have ran into this before. In Samsung we just sent an OTA, as > >> it was no big deal. We either need something like relabeld or a way for > >> the kernel to set the security attribute at file open based on the > >> policy, rather than needing to label.... I'm not a huge fan of labeling. > >> > >> >> Labeling may be painful at times, but all the alternatives are far > >> >> worse. And setting the security attribute at file open would > >> defeat the > >> >> entire purpose. Anyway, that's rather off-topic. > >> >>> Can we start another thread on this, I would love to hear what you > >> know on this. > >> > >> How would consulting the policy before the descriptor being handed out > >> be a security issue? > >> I could see their being performance issues, but considering we have > >> named type transitions for files, isn't this really an extension of > that? > >> > >> We assume that policies are never modified, and if someone can change > >> the policy or the > >> secuirty xattr, then they have won anyways. > >> > > > > > http://securityblog.org/2006/04/19/security-anti-pattern-path-based-access-control/ > > > > > > Most of those are applicable, particularly namespaces, etc. > > > > named type transitions are only the filename, not the path. It is also > > only a labeling hint, policy still has to allow the creator to create > > files of that type. > > Also, let's distinguish open (of an existing file) from create. > It is one thing to compute and set the label of a new file based on > various inputs when it is created (as we already do). It is another > thing to infer the label of an existing file on each open; that's an > implicit typing model ala the TIS DTE work. The latter is necessary if > you want to avoid the initial labeling or relabeling, but it has the > same problems as pathname-based security mechanisms. > > > -- Respectfully, William C Roberts
