linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: PROBLEM: A Capability LSM Module serious bug
       [not found]   ` <20031208161901.7964.qmail@abyss.iscas.cn>
@ 2003-12-08 16:30     ` Serge E. Hallyn
  0 siblings, 0 replies; 3+ messages in thread
From: Serge E. Hallyn @ 2003-12-08 16:30 UTC (permalink / raw)
  To: liangbin01; +Cc: linux-kernel

> you retest in a stupid way!

That's what I said  :)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PROBLEM: A Capability LSM Module serious bug
       [not found]   ` <20031208163618.8789.qmail@abyss.iscas.cn>
@ 2003-12-08 16:48     ` Serge E. Hallyn
  2003-12-08 18:26       ` Chris Wright
  0 siblings, 1 reply; 3+ messages in thread
From: Serge E. Hallyn @ 2003-12-08 16:48 UTC (permalink / raw)
  To: liangbin01; +Cc: linux-kernel, linux-security-module

> I think patch to capability.c maybe a better way to fix this bug. Because 
> dummy.c is a simple superuser mechanism, capability should be not visible 
> to it. And capability modules may be extended to file system so as to 

The main question is do we declare cap_effective to belong solely to
capability.c, or do we want capability.c to trust previous LSM's
computations of those values?  So, even with the current case, if we
insmod, rmmod, then re-insmod capability, do we want to revoke all
previous cap_* computations?

It seems reasonable for it "belong" to capability.c (and I've heard of
noone else wanting to use it).  I just don't think we've explicitly
declared this to be the case.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PROBLEM: A Capability LSM Module serious bug
  2003-12-08 16:48     ` Serge E. Hallyn
@ 2003-12-08 18:26       ` Chris Wright
  0 siblings, 0 replies; 3+ messages in thread
From: Chris Wright @ 2003-12-08 18:26 UTC (permalink / raw)
  To: Serge E. Hallyn; +Cc: liangbin01, linux-kernel, linux-security-module

* Serge E. Hallyn (hallyn@CS.WM.EDU) wrote:
> The main question is do we declare cap_effective to belong solely to
> capability.c, or do we want capability.c to trust previous LSM's
> computations of those values?  So, even with the current case, if we
> insmod, rmmod, then re-insmod capability, do we want to revoke all
> previous cap_* computations?

This is a common issue with the opaque blobs as well.

> It seems reasonable for it "belong" to capability.c (and I've heard of
> noone else wanting to use it).  I just don't think we've explicitly
> declared this to be the case.

Unfortunately, it's currently used by kernel proper.  So we need a
generic solution.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-12-08 18:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20031207121151.22328.qmail@abyss.iscas.cn>
     [not found] ` <20031208144028.GA13813@escher.cs.wm.edu>
     [not found]   ` <20031208161901.7964.qmail@abyss.iscas.cn>
2003-12-08 16:30     ` PROBLEM: A Capability LSM Module serious bug Serge E. Hallyn
     [not found] ` <20031208150809.GA14068@escher.cs.wm.edu>
     [not found]   ` <20031208163618.8789.qmail@abyss.iscas.cn>
2003-12-08 16:48     ` Serge E. Hallyn
2003-12-08 18:26       ` Chris Wright

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).