Hi,
The purpose of this email is not re-opening the old flame on the
anti-LSM "pleas" that were subject of many discussion and
disappointments in certain developers and user groups.
I will try to answer some of those in as much as possible organized
manner, without any personal opinion being show in front of the
objective analysis, and talking from the side of the developer who is
looking at the advantages and shortcomings of different solutions to
achieve almost the same thing (or at least, help when achieving it):
[ http://www.rsbac.org/documentation/lsm.php ]
-> 1. Incompleteness
AFAIK, the LSM framework has evolved much more since it got accepted in
the kernel mainline, many independent hackers contributed to it because
they thought that it needed further improvement, but even if people
could think in the beginning that it was going to be more a weakness
than a real security enhancement, nowadays there are many available
hooks, demonstrating how complete it can be, also, hooks can be added
easily even if there's no (AFAIK, visible) documentation on it (a thing
I'm planning to solve in the forthcoming months, maybe updating the
current documentation at immunix.org), depending on how well the
developer knows about how LSM framework works and how the kernel DAC and
standard checks work themselves.
The point is that people must have in mind that hooks need to work as
they are supposed to do: no ABI/API breaking, no unexpected effects on
"normal operation flow" of the kernel (if it's not explicitly wanted),
no extra overhead or logics messing...etc.
In addition, LKMs using the LSM framework *don't need* to use *only* a
procfs sysctl interface or something alike for providing
user-land<->kernel space communication capabilities.
We have more options: registering a sysfs-based subsystem for example.
During the research I was doing recently on the current hook'ing
architecture, I wrote an useless patch to add a hook for sys_chmod(),
just because I forgot that notify_change() calls an existing LSM hook,
that can handle most file modes changing operation.
I just mean that I'm working daily with them and I forgot *ALL* about
it, so, it's not strange that many people could simply forget that LSM
makes developers and the kernel itself being able of hooks re-using
within similar or related syscalls that have in common some kernel
objects or standard checks.
In short, it's a complicated architecture that needs further research in
order to make solid critics on it, same for RSBAC (which it's not known
for me in terms of internal design and implementation, just having the
idea from the available documentation).
Both are good, but we must admit it, and we must admit that finally LSM
got in mainline and now seems getting more solid and stable.
-> 2. Access Control Only
Yes, and that's noticed from the "official" documentation.
But, who says that we can't place auditing facilities inside the
existing hooks? or even file system linking related tweaks?
Also, why disabling DAC? It's not a good idea if you have to handle
*ALL* at *your OWN*.
And it represents, BTW, a real performance hit because you do *double
checking* or logics overhead.
DAC checks normally *override* LSM checks, except in certain situations
when both pre- and post-processing LSM hooks are used.
An operation must at least be (if no override present): 1) DAC
compliant, 2) LSM->user compliant.
Going into personal thoughts, what's the point of having a *real pain*
and maintenance overhead due to modifying the by-default permissions and
access control basis with your own, even if they can live and have sex
together?
You can split up yours and maintain DAC alone and working with RSBAC
when the user chooses explicitly to use the RSBAC-basis checking, as LSM
does.
-> 3. Low Level Internal Data Structures
I agree that incorrect handling of the structures on-flow can lead to
kernel stack or runtime corruption, but this is nonsense to be claimed
as an LSM fault.
I had freezes many times when I started doing some development with the
LSM framework, but it was more because of my incompetency than the
framework itself.
When new kernel releases hit the streets, LSM framework is stable and
compatible with it, as many people contributes and also the folks
maintaining it are good and responsible ones.
Common mistakes that lead to system take down are more pointer and
structures wrong initialization, but again, those are related with the
developer side.
(It's the cost of doing "low level" sexy-thing development ;) )
-> 4. Stacking
I agree with this, but AFAIK there has been work done in this area, as
far it comes to mind, Serge Hallyn is someone to be asked about it.
Stacking seems not fully support in a out-of-the-box working manner,
nope, you need further work from your side to let other modules using
the framework being subjects of redirection from your hooks.
Anyways, we can even work together on the complete nifty-smooth-good
smelling solution and avoid the need of module stacking :P.
Apart of the joke, yes, this is, at least from my point of view (and I
may be, not may be, sure, mistaken as I've done near to nothing work on
LSM module stacking) a remaining task/feature.
-> 5. Posix Capabilities Without Stacking Support
I don't get the point of these claims.
The LSM framework currently has full support for dynamic and
logic-changeable POSIX.1e capabilities, using the capable() hook and
calling capable(from whatever location inside any other hook to apply
further logic checks (ie. in capable() check for jailed @current process
and deny use of CAP_SYS_CHROOT and CAP_SYS_ADMIN or what-ever-else
capabilities) or in syslog() to deny access to kernel messages stack to
unprivileged users.
Again, I'm not someone to make further comments on stacking-related
issues.
-> 6. No Guaranteed Decision Call
LSM hook architecture is designed (at least on current 2.6 brand) to
return the decision calls results only if they have been successfully
defined and initialized (ie. typical if (ret) { return ret; } ).
Let's see the truth that is out there:
-----
asmlinkage long sys_setgid(gid_t gid)
{
int old_egid = current->egid;
int retval;
retval = security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_ID);
if (retval)
return retval;
(...)
-----
The developer should decide on what logic to use for return a value or
either just return without touching the returned value (this depend
slightly on the operation where are handling and what syscall is
called).
In certain cases we will see teo calls: pre and post processing as I
commented before in this email:
-----
asmlinkage long sys_setuid(uid_t uid)
{
int old_euid = current->euid;
int old_ruid, old_suid, new_ruid, new_suid;
int retval;
retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_ID);
if (retval)
return retval;
(...)
return security_task_post_setuid(old_ruid, old_euid, old_suid,
LSM_SETID_ID);
}
-----
-> 7. Split Up Code
That's just a personal remark, and, at least for me, the framework looks
pretty well structured and code seems as well distributed and organized
In The Right Way (tm).
It's a good point that even a child can understand it and do something
out of it too (I couldn't avoid to make this one).
-> 8. Stateless Calls
As shown above, the hooks get as arguments all the necessary data to
handle the operation and do anything on it to return the "right" result
depending on the followed logic.
Most calls that make use of properties transition such as id's changing
ones (ie. old_suid -> new_suid) are handled with both values.
In short, most time you don't need and *shouldn't* initialize structures
or whatever else, as you may have them available globally, or at least
passed as arguments from the original call to hook in the origin
syscall.
-> 9. Amount of Work
Again it's a personal remark, not objective.
At least from my point of view, I've needed less time to achieve the
same goal by using the LSM framework.
Indeed, at least in 2.6 brand, if you know how to handle it and how
things work or even change between releases, the maintenance overhead is
*minimal*.
-> Final Remarks <-
My thoughts on the personal remarks shown at
http://www.rsbac.org/documentation/lsm.php are pretty short ones:
Immunix, which seems to be the subject of the political,
marketing-related comments has no hand-over-overall-project, and they
failed in most of the things they tried to do, at least from the public
eye such as supporting proprietary modules to do stacking, inode id
structures tweaks and such.
Also, it was a pretty good thing from them this piece of work.
Think that they investors may dislike the model they followed when the
merge happened, anyways, and as an example, I pretty ignore those
patents claims,for example, think that Type Enforcement (TE) is patented
and before SELinux got in mainline the enterprise with rights on the
patent made a public announcement about their "opening" and "for-free"
use of their patented model.
I'm not a lawyer, but if they protest to get that rights back and put
price in our holy heads, they will get in trouble, with investors and
both users and developers.Nobody likes to listen to lies, and if they
did a one, then too much people will be disappointed with them.
I don't think they will do anything like that if they haven't already
done it ;).
All I can say at the end is that we must take a lot of care when looking
at others solutions and try to figure how we can work and improve them
together.
I like both LSM and RSBAC frameworks, RSBAC developers did a great job
and they continue doing it, but, please, we *must* be at least polite
with others work.I don't mean that RSBAC folks didn't be, but we all
know that a lot of bad things were said around.We all do mistakes, is
matter of good intention and effort to don't make them again.
As a little disclaimer, just to say that I'm pretty new here so, maybe
I'm not the best one recall on this, but at least I'm making use of my
rights to comment on it.
Amen or what-ever-else.
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
> Yes, and that's noticed from the "official" documentation.
> But, who says that we can't place auditing facilities inside the
> existing hooks? or even file system linking related tweaks?
Many auditing policies require an audit event to be generated if the operation
is rejected by *either* the DAC (as implemented by the file permissions
and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However,
in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't
even called if the DAC check fails. As a result, if you try to open() a file
and get -EPERM due to the file permissions, the LSM exit isn't called and
you can't cut an audit record there.
El mar, 15-02-2005 a las 23:21 -0500, [email protected] escribi?:
> On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
>
> > Yes, and that's noticed from the "official" documentation.
> > But, who says that we can't place auditing facilities inside the
> > existing hooks? or even file system linking related tweaks?
>
> Many auditing policies require an audit event to be generated if the operation
> is rejected by *either* the DAC (as implemented by the file permissions
> and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However,
> in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't
> even called if the DAC check fails. As a result, if you try to open() a file
> and get -EPERM due to the file permissions, the LSM exit isn't called and
> you can't cut an audit record there.
Yes, there are many cases that apply to such scenario and context, this
may be worth to work on, but think it's main shortcoming is that it cuts
performance and adds further overlapping to the DAC checks, that should
be the first ones being called (as most times they do) and then apply
the LSM basis, so, post-processing will be only required if the DAC
checks get in override or passed, without adding too-much overhead to
the current behavior.
So, I just agree partially, but yes, maybe modifying the DAC checks
themselves and add what-ever-else helper function to handle by-default
auditing in certain operations could be interesting.
I think it could be worthy to have a roadmap in a wiki or even talk
about a one, trying to write it, so, we all could know what needs to be
improved and done, getting a higher percentage of mainline-accepted
approaches.
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
On Wed, 2005-02-16 at 08:29, Lorenzo Hernández García-Hierro wrote:
> Yes, there are many cases that apply to such scenario and context, this
> may be worth to work on, but think it's main shortcoming is that it cuts
> performance and adds further overlapping to the DAC checks, that should
> be the first ones being called (as most times they do) and then apply
> the LSM basis, so, post-processing will be only required if the DAC
> checks get in override or passed, without adding too-much overhead to
> the current behavior.
>
> So, I just agree partially, but yes, maybe modifying the DAC checks
> themselves and add what-ever-else helper function to handle by-default
> auditing in certain operations could be interesting.
Audit is being handled by a separate audit framework, not by LSM. There
is already support in the Linux 2.6 kernel for auditing at syscall exit
(thereby guaranteeing that you capture the final return value in all
cases), with the ability of an LSM to enable such auditing for a
particular event from its hook functions. Further, there is ongoing
work (see the linux-audit mailing list) for a set of audit-related hooks
that will allow auditing based on object identity and the requested mode
separate from any particular LSM.
--
Stephen Smalley <[email protected]>
National Security Agency
--- [email protected] wrote:
> Many auditing policies require an audit event to be
> generated if the operation
> is rejected by *either* the DAC (as implemented by
> the file permissions
> and possibly ACLs) *or* the MAC (as implemented by
> the LSM exit). However,
> in most (all?) cases, the DAC check is made *first*,
> and the LSM exit isn't
> even called if the DAC check fails. As a result, if
> you try to open() a file
> and get -EPERM due to the file permissions, the LSM
> exit isn't called and
> you can't cut an audit record there.
The advice given by the NSA during our B1
evaluation was that is was that in the case
above was that the MAC check should be done
first (because it's more important) and
because you want the audit record to report
the MAC failure whenever possible. The
team advised us that if we didn't do the MAC
check first we would have a tough row to hoe
explaining the design decision and an even
tougher time explaining that the audit of
MAC criteria had been met.
=====
Casey Schaufler
[email protected]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--- Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
wrote:
> ... but think it's main
> shortcoming is that it cuts
> performance
Ya'know, I keep hearing this assertion, but
the evidence of actual system implementations
that have been measured to determine this
"performance impact" is that there is no
difference except in contrived cases. In
contrived cases the performance is better
if you do the "special" checks first.
> and adds further overlapping to the DAC
> checks, that should
> be the first ones being called (as most times they
> do) and then apply
> the LSM basis, so, post-processing will be only
> required if the DAC
> checks get in override or passed, without adding
> too-much overhead to
> the current behavior.
No. There are a number of reasons, including
audit and nearline storage issues that make it
important to do the special checks first. Some
access control schemes may not work if the
Classic DAC check is done first.
> So, I just agree partially, but yes, maybe modifying
> the DAC checks
> themselves and add what-ever-else helper function to
> handle by-default
> auditing in certain operations could be interesting.
I remain a advocate of authoritative hooks.
> I think it could be worthy to have a roadmap in a
> wiki or even talk
> about a one, trying to write it, so, we all could
> know what needs to be
> improved and done, getting a higher percentage of
> mainline-accepted
> approaches.
Sigh.
=====
Casey Schaufler
[email protected]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Wed, 16 Feb 2005 07:52:51 PST, Casey Schaufler said:
> The advice given by the NSA during our B1
> evaluation was that is was that in the case
> above was that the MAC check should be done
> first (because it's more important) and
> because you want the audit record to report
> the MAC failure whenever possible. The
> team advised us that if we didn't do the MAC
> check first we would have a tough row to hoe
> explaining the design decision and an even
> tougher time explaining that the audit of
> MAC criteria had been met.
Fine advice, if the LSM exits had in fact been structured that way.
But the LSM hooks are where they are, and as a result not useful for
auditing. As others noted, the current 2.6 kernel *does* have a separate
audit framework (although it will still report DAC failures in preference
to MAC failures).
I admit having no good idea how to solve that issue, other than having the
audit framework do a dummy LSM call to see if a MAC failure would have been
reported as well if it's an audited syscall. But that's still quite high
on the bletcherous scale....
Hi folks,
this is a late reply, because I was away for a week.
On Dienstag 15 Februar 2005 23:38, Lorenzo Hern?ndez Garc?a-Hierro
wrote:
> The purpose of this email is not re-opening the old flame on the
> anti-LSM "pleas" that were subject of many discussion and
> disappointments in certain developers and user groups.
>
> I will try to answer some of those in as much as possible organized
> manner, without any personal opinion being show in front of the
> objective analysis, and talking from the side of the developer who
is
> looking at the advantages and shortcomings of different solutions to
> achieve almost the same thing (or at least, help when achieving it):
>
> [ http://www.rsbac.org/documentation/lsm.php ]
This is my text, written some time ago. Some of the arguments are
still valid, some others have been discussed in the mean time.
> -> 1. Incompleteness
>
> AFAIK, the LSM framework has evolved much more since it got accepted
in
> the kernel mainline, many independent hackers contributed to it
because
> they thought that it needed further improvement, but even if people
> could think in the beginning that it was going to be more a weakness
> than a real security enhancement, nowadays there are many available
> hooks, demonstrating how complete it can be, also, hooks can be
added
I have no doubt that many small improvements have been done, and LSM
is more complete by now. My main objectives are still valid, though.
> easily even if there's no (AFAIK, visible) documentation on it (a
thing
> I'm planning to solve in the forthcoming months, maybe updating the
> current documentation at immunix.org), depending on how well the
> developer knows about how LSM framework works and how the kernel DAC
and
> standard checks work themselves.
Documentation is a general problem in all projects, not only the
kernel. For me, this has never been an issue against LSM, although
some things, especially the weird stacking, should be documented to
avoid errors in implementation.
> The point is that people must have in mind that hooks need to work
as
> they are supposed to do: no ABI/API breaking, no unexpected effects
on
> "normal operation flow" of the kernel (if it's not explicitly
wanted),
> no extra overhead or logics messing...etc.
Agreed to "not breaking APIs", unless unavoidable to get some
important functionality. And certainly, all extensions must be
optional.
I strongly object against the "no overhead" argument, as I did many
times before. Overhead should be low, and it can be. Security comes
with some costs - you can either say "minimize overhead at all
costs", "maximize security at all costs", or try to make a good
balance. IMHO, the first has been selected as a guide for LSM to get
it accepted for mainline, which I still regard as a bad decision.
As pointed out in another reply, the actual real world overhead is
pretty small - even with more extensive and data gathering hooks like
those of RSBAC. Even making MAC decisions with logging checks before
the Linux DAC decisions should be acceptable, because in almost all
cases access will be granted anyway, so the order of calls does not
matter.
> In addition, LKMs using the LSM framework *don't need* to use *only*
a
> procfs sysctl interface or something alike for providing
> user-land<->kernel space communication capabilities.
> We have more options: registering a sysfs-based subsystem for
example.
This is a portability issue, these interfaces are very Linux specific,
some are even kernel version specific. The good old syscall is very
portable, and you can use a dispatcher to march dozens of calls
through this.
> -> 2. Access Control Only
>
> Yes, and that's noticed from the "official" documentation.
> But, who says that we can't place auditing facilities inside the
> existing hooks? or even file system linking related tweaks?
There is a separate auditing subsystem now, but this was not my point.
Access decisions can be logged where they happen, or in some central
dispatcher.
> Also, why disabling DAC? It's not a good idea if you have to handle
> *ALL* at *your OWN*.
> And it represents, BTW, a real performance hit because you do
*double
> checking* or logics overhead.
Some people even want to override DAC, because it is quite limited. I
agree that this is dangerous - overriding should be off by default,
and there must be a big warning.
Actually, in RSBAC you have separate decisions for every active
decision module - up to 13 decisions for each request, plus the
runtime loaded modules registered through the REG facility. This is
not a problem, if it gives you a real benefit. My usual configuration
has 7 modules active, and the overhead is still low.
> DAC checks normally *override* LSM checks, except in certain
situations
> when both pre- and post-processing LSM hooks are used.
No, they do not override LSM checks - they cannot grant access, if LSM
wants to deny it.
> An operation must at least be (if no override present): 1) DAC
> compliant, 2) LSM->user compliant.
>
> Going into personal thoughts, what's the point of having a *real
pain*
> and maintenance overhead due to modifying the by-default permissions
and
> access control basis with your own, even if they can live and have
sex
> together?
There are cases where Linux DAC and MAC cannot live happily together,
because Linux DAC is too limited.
If you look at the SELinux default policy, you will see that they try
to do everything with SELinux, because only MAC settings are trusted.
Well, sure, this is painful, but can be necessary in some cases.
In RSBAC, you can convert Linux DAC settings to ACLs before switching
DAC off for some directory tree. This gives you complete DAC
settings, but makes them more flexible, fine grained and more MAC
like than standard Linux, because administration is no longer "owner"
based.
> -> 3. Low Level Internal Data Structures
>
> I agree that incorrect handling of the structures on-flow can lead
to
> kernel stack or runtime corruption, but this is nonsense to be
claimed
> as an LSM fault.
Again, I disagree. If you look at the age old discussion RSBAC vs.
SELinux between Stephen Smalley and me, he criticized that even the
few structures available in RSBAC hooks were dangerous.
Now LSM exposes many, many more of them, and expects modules to use
them directly. Most RSBAC modules work without ever touching the few
structures.
> I had freezes many times when I started doing some development with
the
> LSM framework, but it was more because of my incompetency than the
> framework itself.
It is easy to freeze the kernel, but it is much easier, if you must
access lots of structures under locking conditions you do not know
about (and which might change between kernel versions).
> When new kernel releases hit the streets, LSM framework is stable
and
> compatible with it, as many people contributes and also the folks
> maintaining it are good and responsible ones.
It is stable for what it does - most of my points are against design,
not implementation.
> -> 4. Stacking
>
> I agree with this, but AFAIK there has been work done in this area,
as
> far it comes to mind, Serge Hallyn is someone to be asked about it.
The stacking problem is a direct consequence of the design with
distributed single user hooks. It has been criticized from the very
beginning and since then people have been trying to solve it.
Another big problem is that there is only one pointer at some kernel
structures for attribute data - which module is allowed to use this?
The first? Any? How do you know whether it is used or not?
> -> 5. Posix Capabilities Without Stacking Support
>
> I don't get the point of these claims.
> The LSM framework currently has full support for dynamic and
> logic-changeable POSIX.1e capabilities, using the capable() hook and
> calling capable(from whatever location inside any other hook to
apply
> further logic checks (ie. in capable() check for jailed @current
process
> and deny use of CAP_SYS_CHROOT and CAP_SYS_ADMIN or what-ever-else
> capabilities) or in syslog() to deny access to kernel messages stack
to
> unprivileged users.
Without rechecking the current state: At least the last time I
checked, the hardwired kernel capabilities were explicitely disabled
when LSM got switched on. You had to use the capabilities LSM module
instead, which was not able to stack. It always had to be the last in
the chain, thus effectively sealing against any other LSM module to
be loaded later.
Make a short google search for LSM and capabilities, and you will find
loads of user problem reports for this topic. Again, this is only a
consequence of previous design decisions for the hooks, although a
complete implementation of the capability module would have avoided
the problem to show.
> -> 6. No Guaranteed Decision Call
>
> LSM hook architecture is designed (at least on current 2.6 brand) to
> return the decision calls results only if they have been
successfully
> defined and initialized (ie. typical if (ret) { return ret; } ).
You completely missed my point: The first LSM module decides, whether
to call all the others or not, and so on through the chain. Most LSM
modules do not call the others, if they want to deny access
themselves.
This works fine with stateless security models, but it gives you a
hell of a pain for a stateful model - or with non-access control
modules, e.g. for virus scanners, which always want to check even for
denied accesses.
> -> 7. Split Up Code
>
> That's just a personal remark, and, at least for me, the framework
looks
> pretty well structured and code seems as well distributed and
organized
> In The Right Way (tm).
Well, this "personal" and the other problems happen to make LSM
unusable for RSBAC, GRSecurity and others.
The split code argument has another, severe variant:
As all hooks stand independent beside each other and there is no
central decision function, you can never be sure that your LSM module
catches all relevant events in a given kernel version - unless you
inspect every kernel version and either add lots of #ifdefs, or
restrict your module to one single kernel version.
The problem is getting worse (again) with stacking - you can never be
sure, that you pass all relevant events to the modules registered
after yours.
The concept behind the central function is the "reference monitor", a
central component, which is guaranteed to get requests for all
accesses to make access control decisions.
> It's a good point that even a child can understand it and do
something
> out of it too (I couldn't avoid to make this one).
Sorry, but unfortunately, security is usually more complex than what
most children can comprehend. A simple interface does not
automatically make its usage simple. The side effects with locking
and races can be severe.
> -> 8. Stateless Calls
>
> As shown above, the hooks get as arguments all the necessary data to
> handle the operation and do anything on it to return the "right"
result
> depending on the followed logic.
>
> Most calls that make use of properties transition such as id's
changing
> ones (ie. old_suid -> new_suid) are handled with both values.
>
> In short, most time you don't need and *shouldn't* initialize
structures
> or whatever else, as you may have them available globally, or at
least
> passed as arguments from the original call to hook in the origin
> syscall.
Again, this was not my point. For decisions in most real security
models, you need some metadata. You can gather this in the hooks, and
thus avoid direct kernel data structure access, or gather it in the
decision logic. If you do the latter, you have to redo the gathering
in the post call - with possibly different results because of
parallel processes.
> -> 9. Amount of Work
>
> Again it's a personal remark, not objective.
> At least from my point of view, I've needed less time to achieve the
> same goal by using the LSM framework.
What where your goals? Did you have a complete, more extensive
infrastructure, which you had to change to LSM? What models did you
implement?
Similar remarks, but the other way round, have been made for the RSBAC
REG facility. It is also a matter of what you know better and how you
work.
> Indeed, at least in 2.6 brand, if you know how to handle it and how
> things work or even change between releases, the maintenance
overhead is
> *minimal*.
Let me express it this way: I am pretty sure that the implementation
of a given security model is much smaller, less error prone, easier
to port to new kernel versions and probably even significantly faster
without further optimization, if you use the existing RSBAC
infrastructure, than when using LSM hooks.
There are some examples of small LSM modules, which have been quickly
ported to RSBAC and now live in the rsbac/adf/reg subdir as examples
for runtime registration. As they do no longer need to implement
stacking, the code became very small.
> -> Final Remarks <-
>
> My thoughts on the personal remarks shown at
> http://www.rsbac.org/documentation/lsm.php are pretty short ones:
>
> Immunix, which seems to be the subject of the political,
> marketing-related comments has no hand-over-overall-project, and
they
> failed in most of the things they tried to do, at least from the
public
> eye such as supporting proprietary modules to do stacking, inode id
> structures tweaks and such.
Your guess is wrong, I was hinting more at SELinux than at Immunix
here. My statements were political, because many decisions look very
political. And, as explicitely written, they presented my personal
impressions on the whole process.
> Think that they investors may dislike the model they followed when
the
> merge happened, anyways, and as an example, I pretty ignore those
> patents claims,for example, think that Type Enforcement (TE) is
patented
> and before SELinux got in mainline the enterprise with rights on the
> patent made a public announcement about their "opening" and
"for-free"
> use of their patented model.
When this happened, it seemed clear, that after selling the patents
anything could happen. Think of SCO and how they hindered Linux, and
then rethink what problems might appear with clearly accepted patents
all over the business and in various distributions.
Well, I am sure most people here agree that software patents are bad
for free software, so let's not dig into this.
> I'm not a lawyer, but if they protest to get that rights back and
put
> price in our holy heads, they will get in trouble, with investors
and
> both users and developers.Nobody likes to listen to lies, and if
they
> did a one, then too much people will be disappointed with them.
> I don't think they will do anything like that if they haven't
already
> done it ;).
Companies are there to make money, not to provide public benefits.
Sad, but true.
> As a little disclaimer, just to say that I'm pretty new here so,
maybe
> I'm not the best one recall on this, but at least I'm making use of
my
> rights to comment on it.
I appreciate you continued struggle against us thick headed developers
to get a better common solution. Still, some problems are deeper than
they appear, and you will often have politics or even massive company
interests involved.
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
El lun, 21-02-2005 a las 11:19 +0100, Amon Ott escribi?:
> Hi folks,
>
> this is a late reply, because I was away for a week
Hey ao, I was looking for you last week, nice to know you're back
again ;)
>
> Documentation is a general problem in all projects, not only the
> kernel. For me, this has never been an issue against LSM, although
> some things, especially the weird stacking, should be documented to
> avoid errors in implementation.
Yes, I definitely agree with this, it's just that there's a need of
people being able to contribute to it and have something done.
> I strongly object against the "no overhead" argument, as I did many
> times before. Overhead should be low, and it can be. Security comes
> with some costs - you can either say "minimize overhead at all
> costs", "maximize security at all costs", or try to make a good
> balance. IMHO, the first has been selected as a guide for LSM to get
> it accepted for mainline, which I still regard as a bad decision.
Anyways, LSM does *not* provide the solution itself, so, commenting that
the framework achieved such following the point 1 it's not completely
accurate.
It's just the *way* to deploy such security, unless you *deply and
implement* something following such *way*.
The costs come when you stop using the framework itself and making use
of a solution that relies in it, then the overhead it's a thing in
charge of the people who use and design the solution.
> As pointed out in another reply, the actual real world overhead is
> pretty small - even with more extensive and data gathering hooks like
> those of RSBAC. Even making MAC decisions with logging checks before
> the Linux DAC decisions should be acceptable, because in almost all
> cases access will be granted anyway, so the order of calls does not
> matter.
I agree, but it depends on what do you want to achieve with such use of
checks and logics.
> This is a portability issue, these interfaces are very Linux specific,
> some are even kernel version specific. The good old syscall is very
> portable, and you can use a dispatcher to march dozens of calls
> through this.
Of course many interfaces are Linux specific, that's how they wanted to
do them :)
But, for example, this wasn't a reason to stop the effort to port
SELinux functionalities to FreeBSD by the TrustedBSD project.
Maybe it's not all the big the problem seems to be, or at least I hope.
> There is a separate auditing subsystem now, but this was not my point.
> Access decisions can be logged where they happen, or in some central
> dispatcher.
If it achieves the goal that you remark, why you should care on how
exactly auditing happens within the framework if you are going to
externally make use of such features?
> Some people even want to override DAC, because it is quite limited. I
> agree that this is dangerous - overriding should be off by default,
> and there must be a big warning.
Yes, but adding such checks add further overhead and if they are
implmented in a dirty-#if-#etc manner, then it's not up for mainline,
AFAIK, but this should be commented by an "official" kernel folk.
> Actually, in RSBAC you have separate decisions for every active
> decision module - up to 13 decisions for each request, plus the
> runtime loaded modules registered through the REG facility. This is
> not a problem, if it gives you a real benefit. My usual configuration
> has 7 modules active, and the overhead is still low.
Yes, but again, it depends if we are talking about high scalability
systems or whatever uncommon-for-us (at least me, :P) environment.
Then the lowest overhead can't be acceptable.
> No, they do not override LSM checks - they cannot grant access, if LSM
> wants to deny it.
I mean that it depends on when the LSM hook is called, if before or
after the DAC checks.
> There are cases where Linux DAC and MAC cannot live happily together,
> because Linux DAC is too limited.
Agreed.
> Again, I disagree. If you look at the age old discussion RSBAC vs.
> SELinux between Stephen Smalley and me, he criticized that even the
> few structures available in RSBAC hooks were dangerous.
>
> Now LSM exposes many, many more of them, and expects modules to use
> them directly. Most RSBAC modules work without ever touching the few
> structures.
It depends on which scope you're talking about.
From rom the side of the developer, it's a thing in charge of such developer
to bother with them with care.
> It is easy to freeze the kernel, but it is much easier, if you must
> access lots of structures under locking conditions you do not know
> about (and which might change between kernel versions).
I agree with you with that point, anyways, that's a point I can't talk
further.
> The stacking problem is a direct consequence of the design with
> distributed single user hooks. It has been criticized from the very
> beginning and since then people have been trying to solve it.
>
> Another big problem is that there is only one pointer at some kernel
> structures for attribute data - which module is allowed to use this?
> The first? Any? How do you know whether it is used or not?
>
I'm not someone really concerned about the stacking issue as I notice in
my first email, but regarding your structures-related comment.. for
example task_struct or others? normally the structures are defined in a
manner that they can access properties members of other structures (ie.
inode) or make use of globally available structures (ie. current).
What you can't do is to initialize them without knowing if they are
already initialized and so on, again this is more related with developer
side than a weak implementation.
>
> Without rechecking the current state: At least the last time I
> checked, the hardwired kernel capabilities were explicitely disabled
> when LSM got switched on. You had to use the capabilities LSM module
> instead, which was not able to stack. It always had to be the last in
> the chain, thus effectively sealing against any other LSM module to
> be loaded later.
>
Yes, it gets registered as primary but you can pass a disabling argument
to it so it wouldn't prevent you for making use of other modules.
(ie. SELinux uses another "slot").
> You completely missed my point: The first LSM module decides, whether
> to call all the others or not, and so on through the chain. Most LSM
> modules do not call the others, if they want to deny access
> themselves.
I agree with you, but going back to stacking issue then this is just a
consequence.
> This works fine with stateless security models, but it gives you a
> hell of a pain for a stateful model - or with non-access control
> modules, e.g. for virus scanners, which always want to check even for
> denied accesses.
Haven't worked out such features, but will notice after I do it :)
> Well, this "personal" and the other problems happen to make LSM
> unusable for RSBAC, GRSecurity and others.
Yes, it's a personal remark.
> The split code argument has another, severe variant:
>
> As all hooks stand independent beside each other and there is no
> central decision function, you can never be sure that your LSM module
> catches all relevant events in a given kernel version - unless you
> inspect every kernel version and either add lots of #ifdefs, or
> restrict your module to one single kernel version.
Yes, that's maintenance overhead but again a thing that can be solved
with collaboration between both independent developers and the kernel
folks.
> The problem is getting worse (again) with stacking - you can never be
> sure, that you pass all relevant events to the modules registered
> after yours.
> The concept behind the central function is the "reference monitor", a
> central component, which is guaranteed to get requests for all
> accesses to make access control decisions.
>
I agree, the point is that a good stacking design can solve most of
these issues AFAIK.
> Sorry, but unfortunately, security is usually more complex than what
> most children can comprehend. A simple interface does not
> automatically make its usage simple. The side effects with locking
> and races can be severe.
:)
I agree, just didn't wanted to enter into a *real* political flame on
what security can mean for me or others.
> Again, this was not my point. For decisions in most real security
> models, you need some metadata. You can gather this in the hooks, and
> thus avoid direct kernel data structure access, or gather it in the
> decision logic. If you do the latter, you have to redo the gathering
> in the post call - with possibly different results because of
> parallel processes.
Yes.
> > -> 9. Amount of Work
> >
> > Again it's a personal remark, not objective.
> > At least from my point of view, I've needed less time to achieve the
> > same goal by using the LSM framework.
>
> What where your goals? Did you have a complete, more extensive
> infrastructure, which you had to change to LSM? What models did you
> implement?
I didn't re-invented the wheel, didn't needed to change anything within
the LSM framework (at least talking about MAC for example), etc.
I hadn't time to implement further models, but I will give some a try
after I get finished some personal stuff.
> Your guess is wrong, I was hinting more at SELinux than at Immunix
> here. My statements were political, because many decisions look very
> political. And, as explicitely written, they presented my personal
> impressions on the whole process.
It was a good bunch of all of them, just supposed you were talking on
Immunix.
> When this happened, it seemed clear, that after selling the patents
> anything could happen. Think of SCO and how they hindered Linux, and
> then rethink what problems might appear with clearly accepted patents
> all over the business and in various distributions.
>
> Well, I am sure most people here agree that software patents are bad
> for free software, so let's not dig into this.
Sure ;)
> Companies are there to make money, not to provide public benefits.
> Sad, but true.
I can't disagree with this one, but sometimes licenses make companies
doing things they even don't like, which are of our own benefit.
> I appreciate you continued struggle against us thick headed developers
> to get a better common solution.
Just trying to help and make noise around, wondering if something comes
up :)
> Still, some problems are deeper than
> they appear, and you will often have politics or even massive company
> interests involved.
Yes, sadly.
Anyways, it's only a matter of politics, but a really difficult one.
Cheers and many thanks for your comments,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
--- Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
wrote:
> > There are cases where Linux DAC and MAC cannot
> live happily together,
> > because Linux DAC is too limited.
>
> Agreed.
OKay, I'll bite. MAC and DAC are seperate.
How is it that (the limited nature of) the DAC
behavior makes a system with both unhappy?
=====
Casey Schaufler
[email protected]
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
On Montag 21 Februar 2005 18:50, Casey Schaufler wrote:
>
> --- Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
> wrote:
>
>
> > > There are cases where Linux DAC and MAC cannot
> > live happily together,
> > > because Linux DAC is too limited.
> >
> > Agreed.
>
> OKay, I'll bite. MAC and DAC are seperate.
> How is it that (the limited nature of) the DAC
> behavior makes a system with both unhappy?
Back in 2001/2002 (versions 1.1.2 and 1.2.0), I added DAC disabling
support first for the full filesystem, then for selected dir trees
and the converter tool linux2acl to RSBAC. I remember the actual
problem coming from a provider of virtual web servers, but I cannot
find the old mails. Too long ago.
We were not able to solve the given problem without changing the Linux
mode to 0777 (what means disabling DAC effectively). The reason to
add this feature was that the dir mode should not be changed to 0777,
because this would leave it completely unprotected with a non-RSBAC
kernel. Some programs even check Linux modes and refuse to run with
too many rights on their config files (what is usually a good idea,
but sometimes problematic), this is also a convenient workaround for
those.
Personally, I do not use the object based override myself, but rather
subject based override with additional Linux capabilities for
selected accounts and/or programs (which can be set with the RSBAC
CAP module, and which are dangerous because of LD_PRELOAD etc., if
the environment is not controlled). This means that I have to use MAC
configuration to restrict these users/programs afterwards, but that
is not the problem.
The moment you want to implement separation of duty for
administration, you will again and again run against Linux DAC
limits, because it only knows of one single admin. E.g. think of a
separate account doing user management and adding user dirs.
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
--- Amon Ott <[email protected]> wrote:
> On Montag 21 Februar 2005 18:50, Casey Schaufler
> wrote:
> >
> > --- Lorenzo Hern?ndez Garc?a-Hierro
> <[email protected]>
> > wrote:
> >
> >
> > > > There are cases where Linux DAC and MAC cannot
> > > live happily together,
> > > > because Linux DAC is too limited.
> > >
> > > Agreed.
> >
> > OKay, I'll bite. MAC and DAC are seperate.
> > How is it that (the limited nature of) the DAC
> > behavior makes a system with both unhappy?
>
> Back in 2001/2002 (versions 1.1.2 and 1.2.0), I
> added DAC disabling
> support first for the full filesystem ...
There's way to much context missing for
me to make heads or tails of what the issue
was!
=====
Casey Schaufler
[email protected]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Lorenzo Hern?ndez Garc?a-Hierro wrote:
>Also, it was a pretty good thing from them this piece of work.
>Think that they investors may dislike the model they followed when the
>merge happened, anyways, and as an example, I pretty ignore those
>patents claims,for example, think that Type Enforcement (TE) is patented
>and before SELinux got in mainline the enterprise with rights on the
>patent made a public announcement about their "opening" and "for-free"
>use of their patented model.
>
>
You are confused. It is Secure Computing Corporation that holds patents
that threaten SELinux
http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
Immunix has never threatened any open source project with patent
infringement.
Please get your facts straight before accusing someone of a serious act
like that.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
El mi?, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribi?:
> Lorenzo Hern?ndez Garc?a-Hierro wrote:
> You are confused. It is Secure Computing Corporation that holds patents
> that threaten SELinux
> http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
>
> Immunix has never threatened any open source project with patent
> infringement.
You got it wrong, I was talking about SCC, not Immunix, relating the TE
patent, anyways, it's my fault to don't refer to SCC instead of "the
enterprise" which could lead to confusion.I apologize for that.
> Please get your facts straight before accusing someone of a serious act
> like that.
I'm sure I do, haven't accused someone, AFAIK.
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Lorenzo Hern?ndez Garc?a-Hierro wrote:
>El mi?, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribi?:
>
>
>>Lorenzo Hern?ndez Garc?a-Hierro wrote:
>>You are confused. It is Secure Computing Corporation that holds patents
>>that threaten SELinux
>>http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
>>
>>Immunix has never threatened any open source project with patent
>>infringement.
>>
>>
>You got it wrong, I was talking about SCC, not Immunix, relating the TE
>patent, anyways, it's my fault to don't refer to SCC instead of "the
>enterprise" which could lead to confusion.I apologize for that.
>
>
If that is what you meant, then we had no issue.
It looked like you were referring to Immunix because, in the quoted
text, one paragraph only discussed Immunix (by name) and then the
subsequent paragraph just said "them" and then talked about patents.
There was no mention of SCC.
So even if you meant SCC, the casual reader only saw "Immunix" followed
by "patents", and would infer the obvious.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
El mi?, 23-02-2005 a las 14:07 -0800, Crispin Cowan escribi?:
> If that is what you meant, then we had no issue.
>
> It looked like you were referring to Immunix because, in the quoted
> text, one paragraph only discussed Immunix (by name) and then the
> subsequent paragraph just said "them" and then talked about patents.
> There was no mention of SCC.
>
> So even if you meant SCC, the casual reader only saw "Immunix" followed
> by "patents", and would infer the obvious.
Yes, my fault.
I hope this will let readers out of any possible confusion, again, sorry
for any inconveniences, wasn't my intention to create confusion around
Immunix.
At least from my side, I don't have fights nor bad relationships with
anybody from Immunix, but also I just know a very few people from there.
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Hi Amon,
On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote:
> > -> 5. Posix Capabilities Without Stacking Support
> >
> > I don't get the point of these claims.
> > The LSM framework currently has full support for dynamic and
> > logic-changeable POSIX.1e capabilities, using the capable() hook and
> > calling capable(from whatever location inside any other hook to apply
> > further logic checks (ie. in capable() check for jailed @current process
> > and deny use of CAP_SYS_CHROOT and CAP_SYS_ADMIN or what-ever-else
> > capabilities) or in syslog() to deny access to kernel messages stack to
> > unprivileged users.
>
> Without rechecking the current state: At least the last time I
> checked, the hardwired kernel capabilities were explicitely disabled
> when LSM got switched on. You had to use the capabilities LSM module
> instead, which was not able to stack. It always had to be the last in
> the chain, thus effectively sealing against any other LSM module to
> be loaded later.
My patches posted Feb 13 fix this.
If you apply them (and I hope Linus will), capabilities is default
and you can replace that by loading an LSM. You can stack capability
on top of the primary LSM again, if the latter supports this.
Best regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote:
> On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote:
> > Without rechecking the current state: At least the last time I
> > checked, the hardwired kernel capabilities were explicitely
disabled
> > when LSM got switched on. You had to use the capabilities LSM
module
> > instead, which was not able to stack. It always had to be the last
in
> > the chain, thus effectively sealing against any other LSM module
to
> > be loaded later.
>
> My patches posted Feb 13 fix this.
>
> If you apply them (and I hope Linus will), capabilities is default
> and you can replace that by loading an LSM. You can stack capability
> on top of the primary LSM again, if the latter supports this.
Well, not quite, although it is an improvement.
As long as the capabilities module does not support stacking, anybody
needing capabilities and e.g. on-access scanning with Dazuko will
have to unload this module, load another module, and reload it. This
creates a nasty race condition. BTW, what happens if capabilities
have been compiled static, not as a module?
AFAIK, not all LSM modules provide correct stacking. At least all
modules in the main line kernel should really support the official
way. But this is just a few cents from someone not using LSM...
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
On Wed, 2005-02-23 at 13:37 -0800, Crispin Cowan wrote:
> You are confused. It is Secure Computing Corporation that holds patents
> that threaten SELinux
> http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
The NSA made a statement in response to that statement a long time ago,
and in any event, the patents in question have expired AFAICS.
--
Stephen Smalley <[email protected]>
National Security Agency
Hi Amon,
On Thu, Feb 24, 2005 at 09:28:38AM +0100, Amon Ott wrote:
> On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote:
> > If you apply them (and I hope Linus will), capabilities is default
> > and you can replace that by loading an LSM. You can stack capability
> > on top of the primary LSM again, if the latter supports this.
>
> Well, not quite, although it is an improvement.
>
> As long as the capabilities module does not support stacking, anybody
> needing capabilities and e.g. on-access scanning with Dazuko will
> have to unload this module, load another module, and reload it.
Nope.
With the patchset applied you get capabilities as default behaviour,
so with_out_ any LSM loaded.
> This creates a nasty race condition.
You can load any module to replace capabilities. No race condition
(except that the point in time when the security_ops is actually
updated is not well defined as there's no locking nor wmb()).
You can also load the capabilities module on top of the default,
but it won't change any behaviour then (other than eating a few
percent performance in some paths).
> BTW, what happens if capabilities
> have been compiled static, not as a module?
Why would you want to do this?
> AFAIK, not all LSM modules provide correct stacking.
True.
Regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.