Quoting [email protected] ([email protected]):
> +/*
> + * There are not enough CAP bits available to make this
> + * real, so Casey borrowed the capability that looks to
> + * him like it has the best balance of similarity amd
> + * low use.
> + */
> +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
Hey Casey,
note that 64-bit capabilities are now in -mm, so you could grab your own
capability.
-serge
On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> Quoting [email protected] ([email protected]):
> > +/*
> > + * There are not enough CAP bits available to make this
> > + * real, so Casey borrowed the capability that looks to
> > + * him like it has the best balance of similarity amd
> > + * low use.
> > + */
> > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
>
> Hey Casey,
>
> note that 64-bit capabilities are now in -mm, so you could grab your own
> capability.
Which brings up an interesting question - what to do with
security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
Smack - other MAC modules like SELinux won't honor it. Maybe it should
be CAP_SMACK_OVERRIDE.
--
Stephen Smalley
National Security Agency
Quoting Stephen Smalley ([email protected]):
> On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > Quoting [email protected] ([email protected]):
> > > +/*
> > > + * There are not enough CAP bits available to make this
> > > + * real, so Casey borrowed the capability that looks to
> > > + * him like it has the best balance of similarity amd
> > > + * low use.
> > > + */
> > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
> >
> > Hey Casey,
> >
> > note that 64-bit capabilities are now in -mm, so you could grab your own
> > capability.
>
> Which brings up an interesting question - what to do with
> security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
> Smack - other MAC modules like SELinux won't honor it. Maybe it should
> be CAP_SMACK_OVERRIDE.
Yeah, I was thinking it would be renamed to something smack-specific.
The concept of CAP_MAC_OVERRIDE is pretty general, but then users may
for just that reason expect the capability to also let them override
selinux and other capabilities.
For instance the capabilities equivalent to a CAP_MAC_OVERRIDE would
probably be CAP_SETPCAP, since it can be used to add capabilities back
into your inheritable set. But we wouldn't want to share one capability
for CAP_SETPCAP and CAP_SMACK_OVERRIDE. CAP_SETPCAP does let you regain
CAP_SMACK_OVERRIDE, but a process could have CAP_SMACK_OVERRIDE but be
denied CAP_NET_ADMIN for instance, or heck even CAP_DAC_OVERRIDE.
So short answer is: I agree :)
thanks,
-serge
--- Stephen Smalley <[email protected]> wrote:
> On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > Quoting [email protected] ([email protected]):
> > > +/*
> > > + * There are not enough CAP bits available to make this
> > > + * real, so Casey borrowed the capability that looks to
> > > + * him like it has the best balance of similarity amd
> > > + * low use.
> > > + */
> > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
> >
> > Hey Casey,
> >
> > note that 64-bit capabilities are now in -mm, so you could grab your own
> > capability.
A proposal with merit. I'll do it.
> Which brings up an interesting question - what to do with
> security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
> Smack - other MAC modules like SELinux won't honor it. Maybe it should
> be CAP_SMACK_OVERRIDE.
But what about the MAC modules like Smack that do honor it?
They shouldn't be using a module specific capability, so
calling it CAP_SMACK_OVERRIDE isn't right because then the
SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE
and bam, there go all your shiny new capability values. Further,
Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the
access control check, which is not the same thing at all at all.
SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the
restrictive model of the LSM. If someone ported the Trusted
Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't
have to allow read of higher labeled files, as the policy on that
system never allowed that, even for privileged processes.
SELinux has every right to make it's own choices regarding how
it behaves relative to any specific capability because it is
allowed to restrict access in any way it sees fit. I think that
you would get in trouble if you changed the value of a capability
on a task within the LSM, because that will impact the "usual"
access checks, but I wouldn't expect to see you doing that.
SELinux has gone in a different direction on privileged operations
than capabilities, so it's not surprising that the two schemes
don't look like they're meshing very well in this case.
----
* SecureWare was an MLS "kit". The MLS version of HP/UX was based
on it, and the Macintosh version got the first ever CMW evaluation.
SELinux took many of the same design approaches as SecureWare,
and in it's early versions bore a somewhat frightening resemblence
to the earlier system.
** Trix4 allowed a privileged process to write lower labeled files,
but not read higher labeled files. That way any files that got
created "by accident" were assured to be labeled at least as high
as the data they contained.
Casey Schaufler
[email protected]
On Wed, 2007-11-21 at 09:21 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[email protected]> wrote:
>
> > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > > Quoting [email protected] ([email protected]):
> > > > +/*
> > > > + * There are not enough CAP bits available to make this
> > > > + * real, so Casey borrowed the capability that looks to
> > > > + * him like it has the best balance of similarity amd
> > > > + * low use.
> > > > + */
> > > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
> > >
> > > Hey Casey,
> > >
> > > note that 64-bit capabilities are now in -mm, so you could grab your own
> > > capability.
>
> A proposal with merit. I'll do it.
>
> > Which brings up an interesting question - what to do with
> > security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
> > Smack - other MAC modules like SELinux won't honor it. Maybe it should
> > be CAP_SMACK_OVERRIDE.
>
> But what about the MAC modules like Smack that do honor it?
> They shouldn't be using a module specific capability, so
> calling it CAP_SMACK_OVERRIDE isn't right because then the
> SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE
> and bam, there go all your shiny new capability values. Further,
> Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the
> access control check, which is not the same thing at all at all.
> SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the
> restrictive model of the LSM. If someone ported the Trusted
> Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't
> have to allow read of higher labeled files, as the policy on that
> system never allowed that, even for privileged processes.
Well, I'd be surprised to see that SecureWare port to Linux. Or really
any other label-based MAC implementations at all - how many different
ones does Linux need?
Meanwhile, SELinux does implement MAC checks, and those checks do not
require an external privilege mechanism like capabilities and won't be
overridden by your shiny new capability. Which makes me uneasy about
calling it CAP_MAC_OVERRIDE. Explain it to a user - this capability is
for overriding MAC checks, except for SELinux. Or AppArmor or TOMOYO
or ... if you also count them as MAC (depending on your definition of
it).
What the capability does is override the MAC checks in Smack. And since
you don't seem to need more than one such capability for Smack, calling
it CAP_SMACK_OVERRIDE makes sense to me.
> SELinux has every right to make it's own choices regarding how
> it behaves relative to any specific capability because it is
> allowed to restrict access in any way it sees fit. I think that
> you would get in trouble if you changed the value of a capability
> on a task within the LSM, because that will impact the "usual"
> access checks, but I wouldn't expect to see you doing that.
Given that the capability module is implemented via LSM, the above makes
no sense - a LSM is free to tweak the capability bits or change what
capable() returns already. The fact that we don't presently do so is
another matter.
> SELinux has gone in a different direction on privileged operations
> than capabilities, so it's not surprising that the two schemes
> don't look like they're meshing very well in this case.
>
> ----
> * SecureWare was an MLS "kit". The MLS version of HP/UX was based
> on it, and the Macintosh version got the first ever CMW evaluation.
> SELinux took many of the same design approaches as SecureWare,
> and in it's early versions bore a somewhat frightening resemblence
> to the earlier system.
>
> ** Trix4 allowed a privileged process to write lower labeled files,
> but not read higher labeled files. That way any files that got
> created "by accident" were assured to be labeled at least as high
> as the data they contained.
>
>
> Casey Schaufler
> [email protected]
--
Stephen Smalley
National Security Agency
--- Stephen Smalley <[email protected]> wrote:
> On Wed, 2007-11-21 at 09:21 -0800, Casey Schaufler wrote:
> > --- Stephen Smalley <[email protected]> wrote:
> >
> > > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > > > Quoting [email protected] ([email protected]):
> > > > > +/*
> > > > > + * There are not enough CAP bits available to make this
> > > > > + * real, so Casey borrowed the capability that looks to
> > > > > + * him like it has the best balance of similarity amd
> > > > > + * low use.
> > > > > + */
> > > > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
> > > >
> > > > Hey Casey,
> > > >
> > > > note that 64-bit capabilities are now in -mm, so you could grab your
> own
> > > > capability.
> >
> > A proposal with merit. I'll do it.
> >
> > > Which brings up an interesting question - what to do with
> > > security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
> > > Smack - other MAC modules like SELinux won't honor it. Maybe it should
> > > be CAP_SMACK_OVERRIDE.
> >
> > But what about the MAC modules like Smack that do honor it?
> > They shouldn't be using a module specific capability, so
> > calling it CAP_SMACK_OVERRIDE isn't right because then the
> > SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE
> > and bam, there go all your shiny new capability values. Further,
> > Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the
> > access control check, which is not the same thing at all at all.
> > SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the
> > restrictive model of the LSM. If someone ported the Trusted
> > Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't
> > have to allow read of higher labeled files, as the policy on that
> > system never allowed that, even for privileged processes.
>
> Well, I'd be surprised to see that SecureWare port to Linux.
As would I. We have seen the Addmax linux port, however, so
don't expect me to bet a paycheck on SecureWare never coming in.
> Or really any other label-based MAC implementations at all - how many
> different ones does Linux need?
It's no sweat off my nose if we have a dozen. SELinux and Smack are
both general mechanisms. There are situations where very specific
mechanisms would be useful, Smack would be overkill and SELinux
massive overkill. Argue that those mechanisms would never make it
upstream if you like, but I'm not convinced that they don't have a
place.
> Meanwhile, SELinux does implement MAC checks, and those checks do not
> require an external privilege mechanism like capabilities and won't be
> overridden by your shiny new capability. Which makes me uneasy about
> calling it CAP_MAC_OVERRIDE.
SELinux makes all sorts of checks, some of which fall into the
traditional notion of MAC and others (e.g. port binding) that are
not. SELinux has generally eschewed the capabilities paradigm in
favor of enforcing the loaded "policy" and the rules it defines.
> Explain it to a user - this capability is
> for overriding MAC checks, except for SELinux. Or AppArmor or TOMOYO
> or ... if you also count them as MAC (depending on your definition of
> it).
How do you explain the SELinux behavior to a user today?
I have never figured out how to tell if running a given program
against a given file will succeed or fail with SELinux.
If couldn't be that much additional burden to explain.
Put a comment in the reference policy that says:
#
# Policy not affected by CAP_MAC_OVERRIDE
#
> What the capability does is override the MAC checks in Smack. And since
> you don't seem to need more than one such capability for Smack, calling
> it CAP_SMACK_OVERRIDE makes sense to me.
Yes, I understand that that makes some sense given your
assumption that there won't be any more LSMs that would use it.
But I want to be clear that the capability is not overriding
the entire LSM, it is telling the LSM that the process has
"appropriate privilege" and should act accordingly.
An LSM that implements a descretionary mechanism would have
the same opportunity to ignore CAP_DAC_OVERRIDE as SELinux
would to ignore CAP_MAC_OVERRIDE. I think you might have a tough
row to hoe if you're suggesting that CAP_DAC_OVERRIDE should
be changed to CAP_MODEBIT_OVERRIDE.
> > SELinux has every right to make it's own choices regarding how
> > it behaves relative to any specific capability because it is
> > allowed to restrict access in any way it sees fit. I think that
> > you would get in trouble if you changed the value of a capability
> > on a task within the LSM, because that will impact the "usual"
> > access checks, but I wouldn't expect to see you doing that.
>
> Given that the capability module is implemented via LSM, the above makes
> no sense - a LSM is free to tweak the capability bits or change what
> capable() returns already. The fact that we don't presently do so is
> another matter.
Methinks there's a difference between what's possible and what's
allowed here. It's possible for a file system to do the same thing,
but I don't see it being allowed.
That, and you seem to be arguing both sides of the coin. We're both
pointing out that the LSM treats the capabilities as it will. SELinux
restricts port binding even in the presence of the appropriate
capability there.
I really don't see anyone getting their knickers in a twist because
there's another capability that SELinux doesn't honor.
In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
unnecessarily ties it to one LSM, and in spite of what some people
still seem to think, I see more LSMs in the pipeline.
Casey Schaufler
[email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Casey Schaufler wrote:
> In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
> I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
> CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
> unnecessarily ties it to one LSM, and in spite of what some people
> still seem to think, I see more LSMs in the pipeline.
I'd personally not like to see SMACK appear in a capability name. No
offense Casey, but SMACK may be displaced with YAMAC (*) someday, and
I'd hate to have wasted a capability on it. Using CAP_MAC_OVERRIDE makes
sense to me - even if its not (yet/ever) honored by all MAC LSMs.
I do have a question about whether one capability is sufficient in
general for MAC. Looking at the:
http://wt.xpilot.org/publications/posix.1e/download.html
last draft, there are no less than 5 capabilities (p173) allocated for
MAC. Presumably there was a good reason for 5 and not 1 back then -
could you summarize what is different now?
Thanks
Andrew
(*) yet-another example of yet-another
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHR5mc+bHCR3gb8jsRAlB9AJsHPi1+fFp1ONKJCMFDpLS1lYG4AwCfYxMX
8aaU+sOBNHU01uldtrJ8cEI=
=/USy
-----END PGP SIGNATURE-----
--- Andrew Morgan <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Casey Schaufler wrote:
> > In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
> > I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
> > CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
> > unnecessarily ties it to one LSM, and in spite of what some people
> > still seem to think, I see more LSMs in the pipeline.
>
> I'd personally not like to see SMACK appear in a capability name. No
> offense Casey, but SMACK may be displaced with YAMAC (*) someday, and
> I'd hate to have wasted a capability on it.
No offense taken. Technology continues marching forward and all that.
> Using CAP_MAC_OVERRIDE makes
> sense to me - even if its not (yet/ever) honored by all MAC LSMs.
Thanks.
> I do have a question about whether one capability is sufficient in
> general for MAC. Looking at the:
>
> http://wt.xpilot.org/publications/posix.1e/download.html
>
> last draft, there are no less than 5 capabilities (p173) allocated for
> MAC. Presumably there was a good reason for 5 and not 1 back then -
> could you summarize what is different now?
There are to my mind two important differences. The first is that
my experiance with Trusted Irix (Trix from here on), which used (uses?)
capabilities and MAC together, is that the granularity is lost on
99 44/100% of programs, programmers, evaluators, admins, and problems.
You just don't get that many cases where it actually gets you anything
to have less than all the MAC capabilities. Applications that care
about MAC to the extent that they use the capabilities tend to use the
lot, if not all the time, in certain circumstances. I'm afraid that
I am not a major fan of fine grained privilege based on my experiance
with it.
The second and perhaps more important reason is that the POSIX
draft assumed a Bell & LaPadula sensitivity model, or at least
a model very much like it. What would CAP_MAC_DOWNGRADE mean on
a Smack system configured:
OneHand OtherHand r---
OtherHand GrippingHand r---
GrippingHand OneHand r---
What would CAP_MAC_UPGRADE mean, for that matter? It's even worse
to consider that the relationships can change.
CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does
CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can
do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ,
and the other way around, and if you're not going to use one
of the other capabilities after you find out interesting things
using CAP_MAC_READ it's hard to figure why you'd bother.
Now I know that there are lots of people who don't share my
views on granularity, but I have lots of experiance with this
and the cases where it actually makes sense to break the MAC
capabilities up are rare.
That's my going in position, at any rate. I'm always open to
finding out why I'm wrong.
Thank you.
Casey Schaufler
[email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I believe it was you who once eloquently observed that, at its heart,
the POSIX (sic) capabilities model was all about providing a mechanism
for overriding the prevailing security policy (be it MAC or DAC or
whatever) in a defined way.
Casey Schaufler wrote:
> Now I know that there are lots of people who don't share my
> views on granularity, but I have lots of experiance with this
> and the cases where it actually makes sense to break the MAC
> capabilities up are rare.
>
> That's my going in position, at any rate. I'm always open to
> finding out why I'm wrong.
Its not so much why you are wrong, as being clear that we're not using a
generic name and inadvertently limiting ourselves to a SMACK-like model...
It feels to me as if a MAC "override capability" is, if true to its
name, extra to the MAC model; any MAC model that needs an 'override' to
function seems under-specified... SELinux clearly feels no need for one,
and browsing through your SMACK patch, there are many instances where
this capability is used as an convenience privileged override. However,
in other situations, it appears as if the capability is required for
basic SMACK operations to succeed.
My sense is that there is a case to be made for: CAP_MAC_ADMIN and
CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or
whatever MAC supports it) requires privilege to perform a privileged MAC
operation, and the latter for saying "OK, I'm without a paddle but need
one" (or words to that effect).
Cheers
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHR8AA+bHCR3gb8jsRAqY/AJsGI56TDQyBD42LCovpJTYHkaL0pQCdHM5S
kk5v2O4ohY2O0z93JNdKVBY=
=dbQn
-----END PGP SIGNATURE-----
Casey Schaufler wrote:
> --- Andrew Morgan <[email protected]> wrote:
>> I do have a question about whether one capability is sufficient in
>> general for MAC. Looking at the:
>>
>> http://wt.xpilot.org/publications/posix.1e/download.html
>>
>> last draft, there are no less than 5 capabilities (p173) allocated for
>> MAC. Presumably there was a good reason for 5 and not 1 back then -
>> could you summarize what is different now?
>>
> There are to my mind two important differences. The first is that
> my experiance with Trusted Irix (Trix from here on), which used (uses?)
> capabilities and MAC together, is that the granularity is lost on
> 99 44/100% of programs, programmers, evaluators, admins, and problems.
> You just don't get that many cases where it actually gets you anything
> to have less than all the MAC capabilities. Applications that care
> about MAC to the extent that they use the capabilities tend to use the
> lot, if not all the time, in certain circumstances. I'm afraid that
> I am not a major fan of fine grained privilege based on my experiance
> with it.
>
> The second and perhaps more important reason is that the POSIX
> draft assumed a Bell & LaPadula sensitivity model, or at least
> a model very much like it. What would CAP_MAC_DOWNGRADE mean on
> a Smack system configured:
>
> OneHand OtherHand r---
> OtherHand GrippingHand r---
> GrippingHand OneHand r---
>
Shout out to Niven & Pournelle :-)
> What would CAP_MAC_UPGRADE mean, for that matter? It's even worse
> to consider that the relationships can change.
>
> CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does
> CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can
> do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ,
> and the other way around, and if you're not going to use one
> of the other capabilities after you find out interesting things
> using CAP_MAC_READ it's hard to figure why you'd bother.
>
All of that assumes a hierarchical security model (BLP, Biba). This
depends on whether you think "MAC" means:
* specifically the hierarchical models BLP and Biba, or
* any policy system where the rules are mandatory with respect to
the users
The former would include SMACK, the venerable Argus Pitbull system (if
it ever gets ported to LSM), and the recent MLS work implemented on top
of FLASK. It would notably *not* include SELinux's Type Enforcement,
AppArmor, or TOMOYO.
If you take the latter view (a I do) then the meaning of MAC_READ vs.
MAC_WRITE, and especially MAC_RELABEL_SUBJECT, becomes murky, e.g. I
have no clue WtF "relabel subject" means to AppArmor. But I can very
easily understand what "CAP_MAC_OVERRIDE" means to AppArmor.
So I'm with Casey; I support a simple 1-bit capability for MAC override.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
Andrew Morgan wrote:
> Its not so much why you are wrong, as being clear that we're not using a
> generic name and inadvertently limiting ourselves to a SMACK-like model...
>
It seems we all agree that it is a bad idea to tie a POSIX Capability to
one specific LSM model.
> It feels to me as if a MAC "override capability" is, if true to its
> name, extra to the MAC model; any MAC model that needs an 'override' to
> function seems under-specified...
An interesting observation. This is a core part of why I have always
found the hierarchical models BLP and Biba to be unsatisfying. These
systems essentially have one simple fixed policy "process label must
dominate object label to get access", and then you express all the rest
of your "policy" by labeling your stuff. It is impossible to manage such
systems without a MAC_OVERRIDE escape hatch of some kind, because the
"policy" is too simple and inflexible, e.g. it does not allow you to
reclassify anything.
> SELinux clearly feels no need for one,
>
That's not quite right. More specifically, it already has one in the
form of unconfined_t. AppArmor has a similar escape hatch in the "Ux"
permission. Its not that they don't need one, it is that they already
have one. They get to have one because they allow you to actually write
a policy that is more nuanced than "process label must dominate object
label".
> and browsing through your SMACK patch, there are many instances where
> this capability is used as an convenience privileged override. However,
> in other situations, it appears as if the capability is required for
> basic SMACK operations to succeed.
>
> My sense is that there is a case to be made for: CAP_MAC_ADMIN and
> CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or
> whatever MAC supports it) requires privilege to perform a privileged MAC
> operation, and the latter for saying "OK, I'm without a paddle but need
> one" (or words to that effect).
>
I don't get the difference. Both seem to permit the process to violate
the MAC policy. I could make up a meaning for MAC_ADMIN that is
different from MAC_OVERRIDE in the AppArmor sense, but I don't want to
:-) and worse, I suspect the distinction would be different for each
LSM. So let not, and just have one MAC_OVERRIDE capability.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
--- Crispin Cowan <[email protected]> wrote:
> Andrew Morgan wrote:
> > Its not so much why you are wrong, as being clear that we're not using a
> > generic name and inadvertently limiting ourselves to a SMACK-like model...
> >
> It seems we all agree that it is a bad idea to tie a POSIX Capability to
> one specific LSM model.
I think that's fair.
> > It feels to me as if a MAC "override capability" is, if true to its
> > name, extra to the MAC model; any MAC model that needs an 'override' to
> > function seems under-specified...
That's the reason we have a privilege model, not just for
MAC, but DAC as well. The Unix/Linux model where administration
and system tasks are performed by normal processes that are
just a little bit special, as opposed to a completely separate
set of interfaces, often makes things look a little contrived.
This is one of the advantages of SELinux, with it's model of
complete specification.
> An interesting observation. This is a core part of why I have always
> found the hierarchical models BLP and Biba to be unsatisfying. These
> systems essentially have one simple fixed policy "process label must
> dominate object label to get access", and then you express all the rest
> of your "policy" by labeling your stuff. It is impossible to manage such
> systems without a MAC_OVERRIDE escape hatch of some kind, because the
> "policy" is too simple and inflexible, e.g. it does not allow you to
> reclassify anything.
Weeeellllll... That's sort of what the "mandatory" is all about.
> > SELinux clearly feels no need for one,
> >
> That's not quite right. More specifically, it already has one in the
> form of unconfined_t. AppArmor has a similar escape hatch in the "Ux"
> permission. Its not that they don't need one, it is that they already
> have one. They get to have one because they allow you to actually write
> a policy that is more nuanced than "process label must dominate object
> label".
That SELinux doesn't require any capabilities is an artifact of
design on that LSM. The whole notion of privilege is somewhat out
of context when your model is to explicitly state how every possible
decision ought to go. That is one important philosophical difference
between SELinux and Smack, with Smack taking a higher level view
on policy and hence privilege.
> > and browsing through your SMACK patch, there are many instances where
> > this capability is used as an convenience privileged override. However,
> > in other situations, it appears as if the capability is required for
> > basic SMACK operations to succeed.
> >
> > My sense is that there is a case to be made for: CAP_MAC_ADMIN and
> > CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or
> > whatever MAC supports it) requires privilege to perform a privileged MAC
> > operation, and the latter for saying "OK, I'm without a paddle but need
> > one" (or words to that effect).
> >
> I don't get the difference. Both seem to permit the process to violate
> the MAC policy. I could make up a meaning for MAC_ADMIN that is
> different from MAC_OVERRIDE in the AppArmor sense, but I don't want to
> :-) and worse, I suspect the distinction would be different for each
> LSM. So let not, and just have one MAC_OVERRIDE capability.
I am pretty close to agreeing with Andrew that a distinction
between allowing a process to change the state of the MAC
configuration (e.g. set file or process MAC labels, add rules)
and violating the rules is in order. SELinux can ignore both,
AppArmor can ignore one, and the upcoming DG/UX port* can ask for
further granularity when they show up.
I will look in this direction and see if I can patches proposed
before the virus in my sinuses knocks me out completely.
Thank you.
----
* DG/UX supported over 330 capabilities and is my personal
poster child for excesses of granularity with regard to
capabilities. I don't really expect to see a Linux port.
Casey Schaufler
[email protected]
On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote:
> Andrew Morgan wrote:
>> It feels to me as if a MAC "override capability" is, if true to
>> its name, extra to the MAC model; any MAC model that needs an
>> 'override' to function seems under-specified... SELinux clearly
>> feels no need for one,
>
> That's not quite right. More specifically, it already has one in
> the form of unconfined_t. AppArmor has a similar escape hatch in
> the "Ux" permission. Its not that they don't need one, it is that
> they already have one. They get to have one because they allow you
> to actually write a policy that is more nuanced than "process label
> must dominate object label".
Actually, a fully-secured strict-mode SELinux system will have no
unconfined_t processes; none of my test systems have any. Generally
"unconfined_t" is used for situations similar to what AppArmor was
designed for, where the only "interesting" security is that of the
daemon (which is properly labelled) and one or more of the users are
unconfined.
Even then "unconfined_t" is not an implicit part of the policy, it is
explicitly given the ability to take any action on any object by
rules in the policy, and it typically still falls under a few MLS
labeling restrictions even in the targeted policy.
Cheers,
Kyle Moffett
Kyle Moffett wrote:
> On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote:
>> Andrew Morgan wrote:
>>> It feels to me as if a MAC "override capability" is, if true to its
>>> name, extra to the MAC model; any MAC model that needs an 'override'
>>> to function seems under-specified... SELinux clearly feels no need
>>> for one,
>> That's not quite right. More specifically, it already has one in the
>> form of unconfined_t. AppArmor has a similar escape hatch in the "Ux"
>> permission. Its not that they don't need one, it is that they already
>> have one. They get to have one because they allow you to actually
>> write a policy that is more nuanced than "process label must dominate
>> object label".
> Actually, a fully-secured strict-mode SELinux system will have no
> unconfined_t processes; none of my test systems have any. Generally
> "unconfined_t" is used for situations similar to what AppArmor was
> designed for, where the only "interesting" security is that of the
> daemon (which is properly labelled) and one or more of the users are
> unconfined.
Interesting. In a Targeted Policy, you do your policy administration
from unconfined_t. But how do you administer a Strict Policy machine? I
can think of 2 ways:
* reboot to single user and hack away
o hurts usability because you need physical presence to change
policy, but is highly secure
* there is some type that is tighter than unconfined_t but none the
less has sufficient privilege to change policy
o to me, this would be semantically equivalent to
unconfined_t, because any rogue code or user with this type
could then fabricate unconfined_t and do what they want
> Even then "unconfined_t" is not an implicit part of the policy, it is
> explicitly given the ability to take any action on any object by rules
> in the policy, and it typically still falls under a few MLS labeling
> restrictions even in the targeted policy.
Which is more or less the distinction I was trying to draw between
hierarchical systems (MLS) and policy systems (SELinux TE, AppArmor,
etc.) that policy systems let you write yourself an escape hatch in
policy, and MLS systems don't. Or at least they need to kludge something :)
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
> Kyle Moffett wrote:
>> Actually, a fully-secured strict-mode SELinux system will have no
>> unconfined_t processes; none of my test systems have any.
>> Generally "unconfined_t" is used for situations similar to what
>> AppArmor was designed for, where the only "interesting" security
>> is that of the daemon (which is properly labelled) and one or more
>> of the users are unconfined.
>
> Interesting. In a Targeted Policy, you do your policy
> administration from unconfined_t. But how do you administer a
> Strict Policy machine? I can think of 2 ways:
[snip]
> * there is some type that is tighter than unconfined_t but none the
> less has sufficient privilege to change policy
>
> To me, this would be semantically equivalent to unconfined_t,
> because any rogue code or user with this type could then fabricate
> unconfined_t and do what they want
Well, in a strict SELinux system, someone who has been permitted the
"Security Administrator" role (secadm_r) and who has logged in
through a "login_t" process may modify and reload the policy. They
are also permitted to view all files up to their clearance, write
files below their level, and relabel files. On the other hand, they
do not have any system-administration privileges (those are reserve
for sysadm_r).
Under the default policy the security administrator may disable
SELinux completely, although that too can be adjusted as "load
policy" is yet another specialized permission.
Cheers,
Kyle Moffett
Kyle Moffett wrote:
> On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
>> Kyle Moffett wrote:
>>> Actually, a fully-secured strict-mode SELinux system will have no
>>> unconfined_t processes; none of my test systems have any. Generally
>>> "unconfined_t" is used for situations similar to what AppArmor was
>>> designed for, where the only "interesting" security is that of the
>>> daemon (which is properly labelled) and one or more of the users are
>>> unconfined.
>>
>> Interesting. In a Targeted Policy, you do your policy administration
>> from unconfined_t. But how do you administer a Strict Policy machine?
>> I can think of 2 ways:
>
> [snip]
>
>> * there is some type that is tighter than unconfined_t but none the
>> less has sufficient privilege to change policy
>>
>> To me, this would be semantically equivalent to unconfined_t, because
>> any rogue code or user with this type could then fabricate
>> unconfined_t and do what they want
>
> Well, in a strict SELinux system, someone who has been permitted the
> "Security Administrator" role (secadm_r) and who has logged in through
> a "login_t" process may modify and reload the policy. They are also
> permitted to view all files up to their clearance, write files below
> their level, and relabel files. On the other hand, they do not have
> any system-administration privileges (those are reserve for sysadm_r).
>
Ofcourse secadm can give himself privileges to anything he wants, that
isn't necessarily the point though, he is trusted to change the policy.
He is, however, protected from other people: he can't, for example, read
user_home_t files. This protects the integrity of his environment and
the processes he runs. unconfined_t, of course, does not have this
protection.
> Under the default policy the security administrator may disable
> SELinux completely, although that too can be adjusted as "load policy"
> is yet another specialized permission.
>
load policy is pretty course grained, there are ways to make policy
modification privileges more fine grained though such as by using the
policy management server.