On 24/09/10 22:45, Eric Paris wrote: > Right now secmark has lots of direct selinux calls. Use all LSM calls and > remove all SELinux specific knowledge. The only SELinux specific knowledge > we leave is the mode. The only point is to make sure that other LSMs at > least test this generic code before they assume it works. (They may also > have to make changes if they do not represent labels as strings) > > Signed-off-by: Eric Paris <eparis@xxxxxxxxxx> > --- > > include/linux/netfilter/xt_SECMARK.h | 14 ++------ > include/linux/security.h | 25 +++++++++++++ > include/linux/selinux.h | 63 ---------------------------------- > net/netfilter/xt_CT.c | 1 - > net/netfilter/xt_SECMARK.c | 57 +++++++++++++++---------------- > security/capability.c | 17 +++++++++ > security/security.c | 18 ++++++++++ > security/selinux/exports.c | 49 -------------------------- > security/selinux/hooks.c | 24 +++++++++++++ > security/selinux/include/security.h | 1 + > 10 files changed, 116 insertions(+), 153 deletions(-) > > diff --git a/include/linux/netfilter/xt_SECMARK.h b/include/linux/netfilter/xt_SECMARK.h > index 6fcd344..b8d55c4 100644 > --- a/include/linux/netfilter/xt_SECMARK.h > +++ b/include/linux/netfilter/xt_SECMARK.h > @@ -10,19 +10,13 @@ > * 'mode' refers to the specific security subsystem which the > * packets are being marked for. > */ > -#define SECMARK_MODE_SEL 0x01 /* SELinux */ > -#define SECMARK_SELCTX_MAX 256 > - > -struct xt_secmark_target_selinux_info { > - __u32 selsid; > - char selctx[SECMARK_SELCTX_MAX]; > -}; > +#define SECMARK_MODE_SELINUX 0x01 /* SELinux */ > +#define SECMARK_SECCTX_MAX 256 The SECMARK_MODE_SEL is exposed to user-space, even if we have a copy of it in the internal iptables tree, I'm not sure if it's a good policy to change it. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html