Some simple questions: The current discussion of future LSM modules has been capabilities. Is there anyone on the list from the Extended Attributes and ACL project? Does the Linux ACL project plan to exist within the LSM framework? Mike ------------------------------------------ Mike MacCana Long Sig, shortened. On Sun, 15 Apr 2001 linux-security-module-requestat_private wrote: > Send linux-security-module mailing list submissions to > linux-security-moduleat_private > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.wirex.com/mailman/listinfo/linux-security-module > or, via email, send a message with subject or body 'help' to > linux-security-module-requestat_private > > You can reach the person managing the list at > linux-security-module-adminat_private > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of linux-security-module digest..." > > > Today's Topics: > > 1. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Karim Yaghmour) > 2. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Andreas Ferber) > 3. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Crispin Cowan) > 4. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Karim Yaghmour) > 5. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Crispin Cowan) > 6. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Karim Yaghmour) > 7. Re: intercepting system calls (Celestial Wizard) > 8. Re: intercepting system calls (Kurt Seifried) > 9. Re: intercepting system calls (aleph1at_private) > 10. Re: Benchmarks (was Re: Hooking into Linux using the LTT) (Anil B. Somayaji) > > --__--__-- > > Message: 1 > Date: Sun, 15 Apr 2001 21:57:24 -0400 > From: Karim Yaghmour <karymat_private> > To: Crispin Cowan <crispinat_private> > Cc: "Anil B. Somayaji" <somaat_private>, > linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > > > Crispin Cowan wrote: > > > > Acutally, I think 1% overhead at the macro level is very poor. That's > > the overhead for SubDomain with the security checks running in the worst > > possible case. If the basic LSM infrastructure costs 1%, then that's way > > too much. > > That was actually what I was saying, 1% is the worts possible case. > (see my previous posting to see what impact is found for "most" cases"). > > > > > > My hunch is that the LTT represents a rough lower-bound for the > > > performance of a flexible security module interface. > > > > I was thinking of LTT as an upper bound :-) > > I beg to differ and would even go as far as to challenge you to do > better (something I rarely do, by the way). I don't think you can > get any lower of impact with the broad coverage of events provided > by LTT. Remember what this maximum 1% is. It is the cost of inserting > the hooks in the kernel, nothing else. There's no inclusion of any > tracing code in this. The 1% represents an upper bound of how much > it costs to call the trace_event() function at key places in the > kernel. I have a hard time seing how you could reduce this cost > to anything less. Especially since what is being measured is the > time taken to call a single function, that only does a "return", > at key places in the kernel. > > Keep in mind that, in most cases, the impact is lower than 0.25%. > > Cheers, > > Karim > > =================================================== > Karim Yaghmour > karymat_private > Embedded and Real-Time Linux Expert > =================================================== > > > --__--__-- > > Message: 2 > Date: Mon, 16 Apr 2001 04:26:42 +0200 > From: Andreas Ferber <aferberat_private-bielefeld.de> > To: Karim Yaghmour <karymat_private> > Cc: Crispin Cowan <crispinat_private>, > "Anil B. Somayaji" <somaat_private>, linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > > Hi, > > On Sun, Apr 15, 2001 at 09:57:24PM -0400, Karim Yaghmour wrote: > > > > Keep in mind that, in most cases, the impact is lower than 0.25%. > > Someone else already suggested using some sort of bitmap to decide > which hooks are actually plugged in by any security module. Maybe with > this there will be even much less overhead (especially if implementing > the bitmap lookup as a preprocessor macro). > > I will do some testings with the bitmap approach when I have put up a > test machine (I'm getting my hands on some hardware for this, but it > will take some time :-( ). > > We should also think a little bit about hook organization. As pointed > out, we will probably have to deal with several hundred hooks to > manage. I think a hierarchical hook layout will be somewhat helpful > (for example we have the hooks /filesystem/open, /filesystem/delete, > /socket/create and so on). This can also be used for some sort of > hook inheritance (if hook /filesystem/delete is not used, use > /filesystem hook, so that for example a security policy that wants to > completely disable filesystem access only has to plug into /filesystem > and leave the hooks below /filesystem unused). > > Andreas > -- > How much net work could a network work, if a network could net work? > > > > --__--__-- > > Message: 3 > Date: Sun, 15 Apr 2001 20:34:58 -0700 > From: Crispin Cowan <crispinat_private> > Organization: WireX Communications, Inc. > To: Karim Yaghmour <karymat_private> > Cc: "Anil B. Somayaji" <somaat_private>, > linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > > Karim Yaghmour wrote: > > > Crispin Cowan wrote: > > > > My hunch is that the LTT represents a rough lower-bound for the > > > > performance of a flexible security module interface. > > > > > > I was thinking of LTT as an upper bound :-) > > > > I beg to differ and would even go as far as to challenge you to do > > better (something I rarely do, by the way). I don't think you can > > get any lower of impact with the broad coverage of events provided > > by LTT. > > Exactly my point as well. I'm not saying that LTT is bad work; I'm saying > that it is likely far too broad to serve our purpose. I want to start from > ZERO hooks and work up to what is necessary to support an assortment of real > security modules. I don't want to add a lot of functionality that some folks > conjecture is going to be necessary, and I definitely don't want to add a > bunch of stuff because it was in a legacy package like LTT that was designed > for a different purpose. > > > > Remember what this maximum 1% is. It is the cost of inserting > > the hooks in the kernel, nothing else. There's no inclusion of any > > tracing code in this. > > Exactly. And 1% is the cost of running our real security protection. So > porting our module to use LTT as a hook interface would DOUBLE its overhead > load on the kernel, which is way too expensive. The overhead of teh LSM patch > with zero modules loaded should be on the order of 0.1%, i.e. difficult to > measure, much less notice. > > > > The 1% represents an upper bound of how much > > it costs to call the trace_event() function at key places in the > > kernel. I have a hard time seing how you could reduce this cost > > to anything less. Especially since what is being measured is the > > time taken to call a single function, that only does a "return", > > at key places in the kernel. > > > > Keep in mind that, in most cases, the impact is lower than 0.25%. > > I'm sure that LTT is a well-engineered piece of work. We definitely should > learn from it. We probably should use some design elements. We might use > some code. We should not take it as a whole and start building on top. > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > > > > --__--__-- > > Message: 4 > Date: Sun, 15 Apr 2001 23:48:17 -0400 > From: Karim Yaghmour <karymat_private> > To: Andreas Ferber <aferberat_private-bielefeld.de> > Cc: Crispin Cowan <crispinat_private>, > "Anil B. Somayaji" <somaat_private>, linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > > Andreas Ferber wrote: > > > > Someone else already suggested using some sort of bitmap to decide > > which hooks are actually plugged in by any security module. Maybe with > > this there will be even much less overhead (especially if implementing > > the bitmap lookup as a preprocessor macro). > > > > I will do some testings with the bitmap approach when I have put up a > > test machine (I'm getting my hands on some hardware for this, but it > > will take some time :-( ). > > I haven't tried the bitmap approach but have to confess that I find > it quite interesting. Although there are 2 levels to this: compile-time > hook selection and runtime hook reaction. If this for runtime than > the bitmap test would occur after the generlized hooking function > would have been called and in that case you still have to pay the > price of the generalized hooking function being called. > > > We should also think a little bit about hook organization. As pointed > > out, we will probably have to deal with several hundred hooks to > > manage. I think a hierarchical hook layout will be somewhat helpful > > (for example we have the hooks /filesystem/open, /filesystem/delete, > > /socket/create and so on). This can also be used for some sort of > > hook inheritance (if hook /filesystem/delete is not used, use > > /filesystem hook, so that for example a security policy that wants to > > completely disable filesystem access only has to plug into /filesystem > > and leave the hooks below /filesystem unused). > > This hierarchical layout already exists in the patch provided with LTT, > although fine-grained hooks don't exist yet (i.e. you can hook onto > /filesystem, but can't hook to /filesystem/open, but this is easily > implemented). > > Cheers, > > Karim > > =================================================== > Karim Yaghmour > karymat_private > Embedded and Real-Time Linux Expert > =================================================== > > > --__--__-- > > Message: 5 > Date: Sun, 15 Apr 2001 20:54:55 -0700 > From: Crispin Cowan <crispinat_private> > Organization: WireX Communications, Inc. > To: dclydewat_private > Cc: "Anil B. Somayaji" <somaat_private>, > linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > > "\"D. Clyde Williamson\" > > > Has anyone began rudimentary documentation on the whole project? I'd > > love to have a single place to review options and or existing > > architecture bits (like benchmarks). If all we have is the mailing > > list, then perhaps it would be a good idea to start documenting out > > the good stuff for a weekly summary. > > What would we document? When we have a design and some code, it should be > documented . Hopefully we'll have some prototype code out some time this week, > based on the snapshot that Chris W. put out late last week. > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > > > > --__--__-- > > Message: 6 > Date: Mon, 16 Apr 2001 00:49:55 -0400 > From: Karim Yaghmour <karymat_private> > To: Crispin Cowan <crispinat_private> > Cc: "Anil B. Somayaji" <somaat_private>, > linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > > > Crispin Cowan wrote: > > > > Exactly my point as well. I'm not saying that LTT is bad work; I'm saying > > that it is likely far too broad to serve our purpose. I want to start from > > ZERO hooks and work up to what is necessary to support an assortment of real > > security modules. I don't want to add a lot of functionality that some folks > > conjecture is going to be necessary, and I definitely don't want to add a > > bunch of stuff because it was in a legacy package like LTT that was designed > > for a different purpose. > > As I stated before, LTT was designed with the following purposes: > -Dynamic behavior reconstruction > -Performance measurement > -Synchronization-problem solving > -Security auditing > -Intrusion detection > > The reason it can fill all this (and more) is because the hooks insereted > serve all these purposes at once. It seems to me that using > a subset of an existing efficient framework makes more sense > than implementing a limited version of this framework that > will only help one of the possible ends. Notice that one could > modify the way LTT hooks are inserted within the kernel at > compile time by providing fine-grained configuration (i.e. > provide hooks for /filesystem /net /ipc /net/socket and forget > the rest); this too is feasible. > > > Exactly. And 1% is the cost of running our real security protection. So > > porting our module to use LTT as a hook interface would DOUBLE its overhead > > load on the kernel, which is way too expensive. > > Well I'll admit I'm not a fanatic. If 2% is the absolute worst case > to have security on my machine while 90% of cases are around 0.5%, then that's > something I can handle. BUT ... I have an itch that if I'd run the extreme > case I mentionned earlier with a function redirection of your code > (which will be the case once you add whatever hooking interface you > may wish to use) I'd hit 2% without using any LTT hooks. Any patches I can > try? > > > The overhead of teh LSM patch > > with zero modules loaded should be on the order of 0.1%, i.e. difficult to > > measure, much less notice. > > May I point out that "should be" is different from "can be" and I'm afraid > you'll find it hard to reach the 0.1% mark unless you resort to self-modifying > code. Plus I'd really like to see how the "real" security protection you > currently have works and how much overhead it would have if it were simply > encapsulated in an extra call. > > > > > I'm sure that LTT is a well-engineered piece of work. We definitely should > > learn from it. We probably should use some design elements. We might use > > some code. We should not take it as a whole and start building on top. > > > > I'm somewhat disapointed that you might reach such a speedy > conclusion on a piece of software you have not taken the time > to look at. I've been suggesting hooks to provide extensible > and modular security modules for over a year and had posted > messages regarding this more that once on the linux-kernel > mailing list (for example: > http://marc.theaimsgroup.com/?l=linux-kernel&m=95858830028620&w=2) > and have closely studied how hooks impend on system performance. > > I think that there is a real opportunity here for people to > use an already functionnal and flexible hooking layer to > implement their own security modules. Hence my amazement at > your desire "not to take it as whole and start building on > top" without justifying this choice by a clear explanation > of any weakness or limitation you may find (appart from the > performance issue you raise which I'd be willing to test > with your own code to show what I mean). > > In any case, since it seems you are intent on reinventing the wheel, > there's another existing hooking mechanism for the linux kernel > that you may want to take a look at. It's the General Kernel Hooking > Interface provided by the guys at IBM that wrote DProbes: > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes/ > > Contrary to LTT, GKHI does not have a predefined subset of > hooks, it is only a generalized interface to add hooks. Keep > in mind that it is i386-dependant, whereas the LTT hooking > is not. (Although, some hooks have to be added seperately for each > arch. Things like system call entries have to be tapped into by > amending arch/XXX/kernel/entry.S. Currently, the corresponding > directories have been amended for i386 and PPC. SH should be > there soon and so should ARM). > > That being said, I've appended the list of hooks LTT inserts, by > category. You will find that, except for system events like interrupts > and traps, these will probably be the same needed by any general purpose > security module: > System call entry/exit > Trap entry/exit > IRQ entry/exit > Scheduling change > Kernel timer > Soft IRQ > Bottom half > Soft IRQ > Tasklet action > Tasklet hi-action > Process > Kernel thread creation > fork > exit > wait > signal > wakeup > File-system > buffer wait start > buffer wait end > exec > open > close > read > write > seek > ioctl > select > poll > Timer > expired > setitimer > settimeout > Memory > page alloc > page free > swap-in > swap-out > page wait start > page wait end > Socket > call (this includes most socket calls) > create > send > receive > IPC > ipc call (this includes most ipc calls) > msg create > sem create > shm create > Network > packet in > packet out > > Some of these (like filesystem/open) seem like an extra instrumentation > of the system call, but they serve different purposes and can be > used seperately (i.e. not hook onto system calls but hook onto > filesystem/open). > > Cheers, > > Karim > > =================================================== > Karim Yaghmour > karymat_private > Embedded and Real-Time Linux Expert > =================================================== > > > --__--__-- > > Message: 7 > Reply-To: "Celestial Wizard" <celestialwizardat_private> > From: "Celestial Wizard" <celestialwizardat_private> > To: "linux-security-module" <linux-security-moduleat_private> > Subject: Re: intercepting system calls > Date: Mon, 16 Apr 2001 15:07:22 +1000 > > <snip> > > > We could add rules the same way firewalling rules are : in a boot script > > using a userspace tool. > > This mean that the policy is not there at boot time. It is not a problem > > for those who use security policies as modules, but it is for those who > > want to apply their security policy to boot scripts. > > > > An idea (utopia?) could be some persistent data mechanism in the kernel, > > that could also be used for firewalling rules and other parameters > > everywhere in the kernel. (I don't thought a lot about it... storing all > > that in a file near the kernel image ? in the kernel image ? in a separate > > dedicated partition ?) > > </snip> > > What about having the kernel store it somewhere (encrypted partition / fs ?) > that is accesible via VFS (?) so that you cant read it past boot. > the only way to write to this data area, is via a specific runlevel (i know > adding a new run level) that is used only for editing security policies. > when attempting to start in runlevel securityedit, must enter password (not > root passwd!!!!), or key (PKI ?), enter a disk containing key (again PKI?) > before access to that runlevel is allowed. > > for normal boot, kernel reads this data and stores it somewhere. once read, > access (capability?) is then taken out of the kernel for that operation. i > dont think that storing it in memory would be a security risk, as if > userland / bad guy (tm) can read kernel memory, there is no security anyway. > however, resources might be an issue (not sure??) > > > -- > > The Celestial Wizard > President - South East Brisbane Linux Users Group > http://merlin.hatfields.com.au/seblug/ > > Red Hat Certified Engineer > Master RedHat Linux Administrator Certification - Brainbench > Master WindowsNT Administrator Certification - Brainbench > > I don't speak for Microsoft. So please don't speak for me. > > > > > --__--__-- > > Message: 8 > Reply-To: "Kurt Seifried" <listuserat_private> > From: "Kurt Seifried" <listuserat_private> > To: "Celestial Wizard" <celestialwizardat_private>, > "linux-security-module" <linux-security-moduleat_private> > Subject: Re: intercepting system calls > Date: Sun, 15 Apr 2001 23:20:03 -0600 > Organization: Seifried > > Something to please rmemeber when attempting to do all these funky > security policy protection mechanisms: > > A lot of people have remote servers. These servers do not have a > keyboard/monitor. A few (and I mean very few) have serial lines attached > so people can dialin/etc. The vast majority are accessed via ssh/telnet > and other network protocols. > > So what? > > If I cannot modify my security policy by remotely ssh'ing in I can't > really use your security mechanism. I am sure this applies to other > people as well. Please keep this in mind =). > > Kurt Seifried, seifriedat_private > > > > > > --__--__-- > > Message: 9 > Date: Sun, 15 Apr 2001 23:27:49 -0600 > From: aleph1at_private > To: Kurt Seifried <listuserat_private> > Cc: linux-security-module <linux-security-moduleat_private> > Subject: Re: intercepting system calls > > * Kurt Seifried (listuserat_private) [010416 05:21]: > > If I cannot modify my security policy by remotely ssh'ing in I can't > > really use your security mechanism. I am sure this applies to other > > people as well. Please keep this in mind =). > > Thats outside the scope of the work this list is proposing to accomplish > and left to each of the security modules to implement as they see fit. > > -- > Elias Levy > SecurityFocus.com > http://www.securityfocus.com/ > Si vis pacem, para bellum > > > --__--__-- > > Message: 10 > To: Karim Yaghmour <karymat_private> > Cc: linux-security-moduleat_private > Subject: Re: Benchmarks (was Re: Hooking into Linux using the LTT) > From: somaat_private (Anil B. Somayaji) > Date: 15 Apr 2001 23:29:58 -0600 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Karim Yaghmour <karymat_private> writes: > > > > Have you run something like LMBench or HBench-OS on an LTT-enabled > > > kernel? I'd be very curious about the results. It seems like > > > system call latency actually doesn't matter too much under normal > > > workloads - after all, most interesting system calls relate to > > > I/O, which is almost always slow. But if we are to get anything > > > incorporated into the main kernel tree, we have to show that our > > > modifications have minimal impact on system call and interrupt > > > latency. > > > > The impact is minimal as can be. You can check the code to that > > effect. That being said, I haven't run micro-benchmarks because > > I usually view them with caution (a fact that some reviewers > > of the Usenix paper actually agreed on). I tend to think that > > micro-benchmarks reflect fringe behavior that _may_ have little > > to do with reality, hence the use of macro-benchmarks. > > Hey, I certainly agree micro-benchmarks don't tell you what will > happen under normal loads. Certainly, I've noticed that - my code > blows donkeys in micro-benchmarks, but I have a hard time measuring > the impact at a macro level! > > Having said that, I believe this is a case of "knowing your audience." > Linus, Alan, and others definitely care about micro-benchmarks, and > they regularly refer to the results of programs like lmbench when > evaluating the impact of different changes. After all, people have > gotten kudos for tweaking the entry.S assembly code by removing one or > two unnecessary instructions. > > So, you see, if we're going to get anything included in the kernel, it > is going to have to be extremely minimal in the generic case - > otherwise, it will not get included. > > You believe that, based on your macro-benchmarks, that the performance > of the LTT is good enough. All I'm saying is that I'm not so sure > that it will be so at the micro-level. The LTT may be the most > efficient way to implement the functionality it does; that isn't > enough to convince non-security people, though, that its overhead is > worth it. > > In the next day or so I'll try posting a message explaining what I'd > need from a security-module interface to implement my code as a > module; my description may not be a good place to start on a general > design, though, because it may be _impossible_ to design an interface > that is flexible enough to do what I need it to do, and efficient > enough to be included in the mainline kernel. > > What we need is an interface that can accomodate POSIX, and hopefully > a few other models such as SubDomain that the general community might > care about. In the end, I doubt the interface we come up with will be > sufficient to implement more research-oriented projects - for those, > something like the Linux Trace Toolkit may be the right starting > point. > > --Anil > > - -- > Anil Somayaji (somaat_private) > http://www.cs.unm.edu/~soma > +1 505 872 3150 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (GNU/Linux) > > iEYEARECAAYFAjragzsACgkQXOpXEmNZ3SeNnACfRED1hO1H1JBCJzlcPAphvy8I > JQAAn2uoYhcDT7bQVdGt62JMY0944Iol > =Ry2v > -----END PGP SIGNATURE----- > > > > --__--__-- > > _______________________________________________ > linux-security-module mailing list > linux-security-moduleat_private > http://mail.wirex.com/mailman/listinfo/linux-security-module > > > End of linux-security-module Digest > _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Apr 16 2001 - 01:18:23 PDT