On Thu, 27 Jan 2005 23:20:03 EST, John Richard Moser said:
> This patch has been tested with 3 dummy modules to do transparent
> stacking.
Have you looked at Serge Hallyn's work in this area?
> The dummy modules produce unique output with
> printk(KERN_INFO) when you cat /proc/self/maps. There's also a kernsec
> module to implement GrSecurity linking restrictions and partial /proc
> restrictions, which I wrote to learn how those work.
Yow.. A 110K patch that includes more than one thing.. ;)
+#define _GRSECURITY_DO(function,...) \
+do {\
+ struct grsecurity_operations *ops; \
+ read_lock(&gr_ops_lock); \
+ for (ops = grsecurity_ops; ops; ops = ops->next) { \
+ if ( ops->function ) \
+ ops->function ( __VA_ARGS__ ) ; \
+ } \
+ read_unlock(&gr_ops_lock); \
+} while(0)
This is only used in gr_inode_handle_create() - what happens if one of the
functions manages to throw an error? Do you *really* want to continue
if one of your stacked modules has just said "I can't label this inode for
later security checking"?
This archive was generated by hypermail 2.1.3 : Thu Jan 27 2005 - 22:26:45 PST