login
Header Space

 
 

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Stephen Smalley <sds@...>, Lars Marowsky-Bree <lmb@...>
Cc: James Morris <jmorris@...>, Pavel Machek <pavel@...>, Crispin Cowan <crispin@...>, Greg KH <greg@...>, Andreas Gruenbacher <agruen@...>, <jjohansen@...>, <linux-kernel@...>, <linux-security-module@...>, <linux-fsdevel@...>
Date: Friday, June 22, 2007 - 12:06 pm

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

 

Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control
  "The TCB shall enforce a mandatory access control policy over
   all subjects and storage objects under its control."

Chapter and verse: TCSEC 3.2.1.4 Mandatory Access Control
  "The TCB shall enforce a mandatory access control policy over
   all resources that are directly or indirectly accessible by
   subjects external to the TCB."

The first reference is in the definition of a B1 system, while the
second is for a B2 system. It was made clear to those of us
doing TCSEC evaluations that there is a very real distintion between
these two requirements. In the history that I've been through,
starting in 1987, the B1 requirement has been read to allow for
things that are not storage objects to be uncontrolled while the
B2 requirement does not. If everything is a storage object, which
is the approach everybody took, yes, you're looking at system wide.
If, on the other hand, you were to take a different model approach
and say that networking does not use storage objects you would not
have to account for them under the B1 rules, while you would still
have to for B2. Historically, no one succeeded with B2, and the
mindset of B1 prevailed. So, historically, the understanding was
that it was easier to declare everything a storage object and code
up some MAC for it than it was to provide a security model that
explained networking as it really works. I suggest that if AA wants
to declare that as far as they are concerned sockets, ports, and
packets are none of them storage objects but are instead pregnant
weasels that is their peragotive as system designers and that
a B1 evaluation team would have accepted that, provided sufficient
evidence and explaination of the relevence of pregnant weasels
was provided. It would not have worked at B2, but historically
everyone understood that B2 was out of reach.

Stephen is correct in that historically everyone implemented system
that put everything under MAC, but is not in that it was well
understood that if you could define something as not being a
storage object you didn't have to submit it to MAC. Then as now
it was easier to get people to code MAC than to get them to write
papers about the security properties of pregnant weasels.



Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Mon Jun 4, 5:03 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Fri Jun 8, 6:03 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 12:08 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 3:35 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 3:24 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 4:21 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 3:54 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Fri Jun 22, 8:42 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Tue Jun 26, 4:50 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 5:17 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Fri Jun 22, 7:37 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Casey Schaufler, (Fri Jun 22, 12:06 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Fri Jun 22, 8:54 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Fri Jun 22, 6:49 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Thu Jun 21, 8:19 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Thu Jun 21, 12:01 pm)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Fri Jun 22, 5:59 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Thu Jun 21, 11:54 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Sat Jun 9, 11:05 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Andreas Gruenbacher, (Sat Jun 9, 11:17 am)
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulat..., Lars Marowsky-Bree, (Tue Jun 12, 1:03 pm)
speck-geostationary