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 <lorenzo@private> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
This archive was generated by hypermail 2.1.3 : Mon Feb 21 2005 - 09:18:09 PST