| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Oct 2010 10:50:05 -0700 From: Casey Schaufler <casey@...aufler-ca.com> To: Ingo Molnar <mingo@...e.hu> CC: Eric Paris <eparis@...hat.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, linux-fsdevel@...r.kernel.org, hch@...radead.org, zohar@...ibm.com, warthog9@...nel.org, david@...morbit.com, jmorris@...ei.org, kyle@...artin.ca, hpa@...or.com, akpm@...ux-foundation.org Subject: Re: [PATCH 1/3] IMA: move read/write counters into struct inode On 10/22/2010 1:48 AM, Ingo Molnar wrote: > * Casey Schaufler <casey@...aufler-ca.com> wrote: > >> On 10/20/2010 8:15 AM, Ingo Molnar wrote: >>> * Eric Paris <eparis@...hat.com> wrote: >>> >>>> On Wed, 2010-10-20 at 16:38 +0200, Ingo Molnar wrote: >>>>> * Eric Paris <eparis@...hat.com> wrote: >>>>> >>>>>> Executive summary of the day's work: >>>>>> Yesterday morning: 944 bytes per inode in core >>>>>> Yesterday night: 24 bytes per inode in core >>>>>> Tonight: 4 bytes per inode in core. >>>>>> >>>>>> That's a x236 time reduction in memory usage. No I didn't even start looking >>>>>> at a freezer. Which could bring that 4 down to 0, but would add a scalability >>>>>> penalty on all inodes when IMA was enabled. >>>>> Why not use inode->i_security intelligently? That already exists so that way >>>>> it's 0 bytes. >>>>> >>>>> Thanks, >>>> It still wouldn't be 0 bytes since there would be a 1-1 mapping from inode to >>>> i_security structs. [...] >>> Only for IMA-affected files, right? >>> >>> My point is to keep it 0 overhead for the _non IMA common case_. >>> >>>> The real reason I don't pursue this route is because of the litany of different >>>> ways this pointer is used in different LSMs (or not used at all.) And we all know >>>> that LSM authors aren't known for seeing the world the same way as each other. As >>>> a maintainer of one of those LSMs even I'm scared to try pushing that forward.... >>> Ugh. That's a perfect reason to do it exactly like i suggested. >> If you would like to make a proposal on LSM stacking other than the traditional >> "rip the LSM out" I am sure that everyone in the IMA, SELinux, TOMOYO, AppArmor >> and Smack communities would be happy to have a look. Short of having a viable >> mechanism for multiple LSMs to coexist IMA needs its separate space. Yes, people >> do use both IMA and LSMs on the same machine at the same time. > Yes, that's the essence of what i suggested: if various security concepts can be > present at once then inode->security should not be a stupid pointer to a single, > exclusive data structure (because that hardwires a "only a single security subsystem > active" assumption), but should be a pointer to a linked list of security structures > - as many as there are security subsystems interested in that inode. Glad to see support for an LSM module stacker (modulator, combiner, ...) growing. All we really need to do is get someone a case of the beverage of their choice and turn them loose on the problem. I think that the few anti-stacking holdouts (I was one, but converted a couple years ago) can be swayed by a reasonable implementation. It won't be easy, there are plenty of problems that need to be solved, but anyone who wants easy should stick to developing web portals and stay out of the kernel. > > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists