netdev - [RFC] Wild and crazy ideas involving struct sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200708221631.34234.paul.moore@hp.com>
Date:	Wed, 22 Aug 2007 16:31:34 -0400
From:	Paul Moore <paul.moore@...com>
To:	netdev@...r.kernel.org
Subject: [RFC] Wild and crazy ideas involving struct sk_buff

Over in LSM/SELinux land there has been a lot of talk recently about how to 
deal with loopback and forwarded traffic, specifically, how to preserve the 
sender's security label on those two types of traffic.  Yes, there is the 
existing sk_buff.secmark field but that is already being used for something 
else and utilizing it for this purpose has it's pros/cons.

We're currently talking about several different ideas to solve the problem, 
including leveraging the sk_buff.secmark field, and one of the ideas was to 
add an additional field to the sk_buff structure.  Knowing how well that idea 
would go over (lead balloon is probably an understatement at best) I started 
looking at what I might be able to remove from the sk_buff struct to make 
room for a new field (the new field would be a u32).  Looking at the sk_buff 
structure it appears that the sk_buff.dev and sk_buff.iif fields are a bit 
redundant and removing the sk_buff.dev field could free 32/64 bits depending 
on the platform.  Is there any reason (performance?) for keeping the 
sk_buff.dev field around?  Would the community be open to patches which 
removed it and transition users over to the sk_buff.iif field?  Finally, 
assuming the sk_buff.dev field was removed, would the community be open to 
adding a new LSM/SELinux related u32 field to the sk_buff struct?

Thanks.

-- 
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html