Re: [Apparmor-dev] Object Capabilities for AppArmor
I've tried to process your, Peter and and Mark's feedback and just placed a revised version of my first draft on http://polacanthus.net/fdoc.html I've attempted to clearify some points that I understood to be unclear from feedback I got, and tried to make modifications from your usefull input. I hope the updated doc will help in the discussion. I currently have aproximately 300 hours planned for work on this over the next 10 to 13 months, either as a seperate LSM module or as a part of AppArmor (including the time I'll need to get up to speed with kernel development and AppArmor specifics). I'll be abel to be on the irc channel sunday anywhere from 12:00 till 17:00 or anywhere from 19:00 till 23:00 localtime (I'm on GMT+1). Rob On Sat, November 17, 2007 20:18, Crispin Cowan wrote: > From various discussions in these mailing lists, I have recently moved > from on-the-fence to inclined in favor of adding some Object > Capabilities to the AppArmor system. However, because of the UNIX > legacy, and the way that AppArmor is intended to work, it cannot be a > pure OC system, it will have to be some kind of a hybrid. I particularly > like the file descriptor OC hybrid that Rob Meijer has proposed, but > will need some refinement. > > For example, in UNIX file descriptors are left open on exec(), unless > you do something to close them. Sometimes software deliberately leaves > file descriptors open as a parameter passing technique, but there is > also a chronic sequence of security vulnerabilities where FDs are > unintentionally left open. Thus AppArmor needs some kind of policy > mechanism to specify whether FDs should be left open on exec() in > particular circumstances. > > To figure out just how to do this, I propose a discussion on the > apparmor-dev mailing list (where the reply-to: is pointed) and a virtual > conference in the #apparmor IRC room. American Thanks Giving holiday is > coming, so I propose approximately a week's discussion, and a virtual > conference in #apparmor on Sunday November 25th. The exact date & time > of the virtual conference can be determined in follow-ups to this post > on apparmor-dev. > > Please join this discussion if you are interested. apparmor-dev holds > non-member posts for moderation by a human. The human policy is to > filter spam only, but if you want your posts to go straight through > unmoderated, please subscribe to apparmor-dev, it is not a high volume > list. Well, it wasn't until just now :) > > Thanks, > Crispin > > -- > Crispin Cowan, Ph.D. http://crispincowan.com/~crispin > CEO, Mercenary Linux http://mercenarylinux.com/ > Itanium. Vista. GPLv3. Complexity at work > > ___ > Apparmor-dev mailing list > [EMAIL PROTECTED] > http://forge.novell.com/mailman/listinfo/apparmor-dev > > - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
Peter Dolding wrote: > On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > >> --- Peter Dolding <[EMAIL PROTECTED]> wrote: >>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: >>> Peter Dolding wrote: > Assign application to > a cgroup that contains there filesystem access permissions. Done > right this could even be stacked. Only give less access to > application unless LSM particularly overrides This comes no where close to AppArmor's functionality: * Can't do learning mode * Can't do wildcards * Sucks up huge loads of memory to do that much FS mounting (imagine thousands of bind mounts) * I'm not sure, but I don't think you can do file granularity, only directorie >>> Ok sorry to say so far almost percent wrong. Please note netlabels >>> falls into a control group. All function of Apparmor is doable bar >>> exactly learning mode. For learning mode that would have to be a >>> hook back to a LSM I would expect. >>> >>> Done right should suck up no more memory than current apparmor. But >>> it will required all LSM's doing file access to come to common >>> agreement how to do it. Not just hooks into the kernel system any >>> more. >>> >> The ability to provide alternative access control schemes is the >> purpose of LSM. The fact that we insane security people can't come >> to the agreement you require is why we have LSM. You can not have >> what you are asking for. Please suggest an alternative design. >> > Part of the building the alternative design requires aggreeing to > build sections common. > Ok. I vehemently disagree with your design ideas. So do lots of other people, and I have not seen one single person ever speak up in favor of your ideas. So far, you have no agreement at all. Containers and access controls provide related but different functions. Stop trying to force containers to be an access control system, it does not fit well at all. Rather, we need to ensure that LSM and containers play well together. What you proposed in the past was to have an LSM module per container, but I find that absurdly complex: if you want that, then use a real VMM like Xen or something. Containers are mostly used for massive virtual domain hosting, and what you want there is as much sharing as possible while maintaining isolation. so why would you corrupt that with separate LSM modules per container? >>> Please stop being foolish. Xen and the like don't share memory. You >>> are basically saying blow out memory usage just because someone wants >>> to use a different LSM. >>> >> Yup. No one ever said security was cheap. Most real, serious security >> solutions implemented today rely on separate physical machines for >> isolation. Some progressive installations are using virtualization, >> and the lunatic fringe uses the sort of systems well served by LSM. >> Let's face it, people who really care are willing to pay a premium. >> > > Bigger problem Containers are processor neutral Xen and lot of the > other solutions are not. There are advantages for people who don't > need full blown. There needs to be two levels. Ie VM for the heavy. > Containers for where the security is needed but no to the point of > needing two different kernels. Remarkable. I agree completely with this paragraph, but draw the opposite conclusion that you do. Having private LSMs per container means having a separate kernel per container. That would seem to put that idea in the "heavy" category. Which is why I suggested that people who want to do what you desire should use full VMM instead of containers. > Now restricting what can be in a > Container due to some poor reason that has not been attempted to be > worked around is not a valid reason. It is rejected for perfectly sound engineering reasons like complexity bloat and memory bloat. Come back with a workable design or STFU. >In theory using Containers you > should be able to run every Linux distro on earth under one kernel as > long as it supports that series kernel. Ie 2.6 2.4... In "theory" as long as this theory ignores the fact that all distros patch their kernel. So yeah, you can run different "distros" as long as you don't care about device support, and you ignore which LSM you want to use. Containers fundamentally share the kernel, and the LSM module(s) loaded are part of the kernel, and therefore are fundamentally shared among the Containers. >>> Besides file access control is part of running containers isolated in >>> the first place and need to be LSM neutral. >>> >> File access control is within the scope of the LSM. If your feature >> can't deal with that you need to fix your feature. >> > This is the problem for containers File access controls need to be > like netlabels common between LSM's.
Re: [PATCH] 64bit capability support (legacy support fix)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Morgan wrote: > Andrew, > > The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies > against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and > Andy - ultimately, the legacy support wasn't transparent. In particular, > userspace 32-bit capability manipulations (when run by root) that used > to work, without this patch, fail. > This works for me. I guess the appropriate line is: Tested-by: Kevin Winchester <[EMAIL PROTECTED]> - -- Kevin Winchester -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQHkqKPGFQbiQ3tQRAt/uAJ9bWz4XHFDkavlCsl4wyT91KXa5GQCfZ3t1 4fy44s2RVnNDQaVJasf4OF0= =QMO4 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > > > --- Peter Dolding <[EMAIL PROTECTED]> wrote: > > > On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: > > > Peter Dolding wrote: > > > >>> What is left unspecified here is 'how' a child 'with its own profile' > > is > > > >>> confined here. Are it is confined to just its own profile, it may that > > > >>> the "complicit process" communication may need to be wider specified > > > >>> to > > > >>> include this. > > > >>> > > > > Sorry have to bring this up. cgroups why not? > > > Because I can't find any documentation for cgroups? :) > > > > > > > Assign application to > > > > a cgroup that contains there filesystem access permissions. Done > > > > right this could even be stacked. Only give less access to > > > > application unless LSM particularly overrides. > > > > > > > This comes no where close to AppArmor's functionality: > > > > > > * Can't do learning mode > > > * Can't do wildcards > > > * Sucks up huge loads of memory to do that much FS mounting (imagine > > > thousands of bind mounts) > > > * I'm not sure, but I don't think you can do file granularity, only > > > directories > > > > > Ok sorry to say so far almost percent wrong. Please note netlabels > > falls into a control group. All function of Apparmor is doable bar > > exactly learning mode. For learning mode that would have to be a > > hook back to a LSM I would expect. > > > > Done right should suck up no more memory than current apparmor. But > > it will required all LSM's doing file access to come to common > > agreement how to do it. Not just hooks into the kernel system any > > more. > > The ability to provide alternative access control schemes is the > purpose of LSM. The fact that we insane security people can't come > to the agreement you require is why we have LSM. You can not have > what you are asking for. Please suggest an alternative design. Part of the building the alternative design requires aggreeing to build sections common. Like the netlabels. We need this for other parts like filesystems. > > > At the container entrance point there needs file granularity applied > > for complete and correct container isolation to be done. > > > > > > > There are reasons why I keep on bring containers up it changes the > > > > model. Yes I know coming to a common agreement in these sections will > > > > not be simple. But at some point it has to be done. > > > > > > > Containers and access controls provide related but different functions. > > > Stop trying to force containers to be an access control system, it does > > > not fit well at all. > > > > > > Rather, we need to ensure that LSM and containers play well together. > > > What you proposed in the past was to have an LSM module per container, > > > but I find that absurdly complex: if you want that, then use a real VMM > > > like Xen or something. Containers are mostly used for massive virtual > > > domain hosting, and what you want there is as much sharing as possible > > > while maintaining isolation. so why would you corrupt that with separate > > > LSM modules per container? > > > > Please stop being foolish. Xen and the like don't share memory. You > > are basically saying blow out memory usage just because someone wants > > to use a different LSM. > > Yup. No one ever said security was cheap. Most real, serious security > solutions implemented today rely on separate physical machines for > isolation. Some progressive installations are using virtualization, > and the lunatic fringe uses the sort of systems well served by LSM. > Let's face it, people who really care are willing to pay a premium. Bigger problem Containers are processor neutral Xen and lot of the other solutions are not. There are advantages for people who don't need full blown. There needs to be two levels. Ie VM for the heavy. Containers for where the security is needed but no to the point of needing two different kernels. Now restricting what can be in a Container due to some poor reason that has not been attempted to be worked around is not a valid reason. In theory using Containers you should be able to run every Linux distro on earth under one kernel as long as it supports that series kernel. Ie 2.6 2.4... Now that is only the base level of Containers. More advanced Zones like solaris will see other platforms running in a container under the same kernel. Current designing around containers is not dealing with what I can do. It more how will we hack it to work. Not make sure it will support where Container design can go. > > > Besides file access control is part of running containers isolated in > > the first place and need to be LSM neutral. > > File access control is within the scope of the LSM. If your feature > can't deal with that you need to fix your feature. This is the problem for containers File access controls need to be like netlabels common between
