Re: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=yand CONFIG_PRINTK=n

[James Morris]

On Mon, 15 Nov 2010, Eric Paris wrote:

> On Mon, Nov 15, 2010 at 12:41 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > If the old rule should have been that you _have_
> > to call cap_syslog(), then just eviscerating that entirely and putting
> > it in the generic code is definitely the right thing.
> 
> That is the rule for ALL of the hooks in commoncap.c.  The one time I
> tried to do something else *cough*mmap_min_addr*cough* I screwed it
> up.  I'll put a note in my todo list about looking into lifting all of
> commoncap.c into the callers.

If it's a requirement of the API that all of the cap calls are made 
first, then build it into the API, so developers can't make a mistake.  
e.g. have the LSM API do the secondary stacking of caps behind the scenes.

I had thought that the idea was that some LSM may want to not implement 
capabilities at all, on which case, it should still not be possible for 
the API to weaken the default security with or without caps.  In any case, 
mixing generic logic with capabilities logic seems to be a fundamental 
issue, and one which we should avoid, and remove where it may exist (I did 
audit the hooks after the mmap_min_addr thing, but it's worth checking 
again).


- James
-- 
James Morris
<jmorris@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/