Re: [RFC 0/4] NetLabel
James Morris wrote:
On Thu, 25 May 2006, Paul Moore wrote:
This patch introduces a new kernel feature designed to support labeled
networking protocols such as RIPSO and CIPSO. These protocols are required to
interoperate with existing trusted operating systems such as Trusted
Solaris.
A few initial comments.
- Did you decide that you definitely need to verify labels on fragments?
I can see the code's been added to do that, but wonder about a comment
made during earlier discussion that mislabeled fragments could only come
from a misbehaving trusted system. What is the threat model here?
This is one part of the patch that I really don't have a strong feeling
for either way. There was some concern on the LSM list that not
checking the fragment options might be an issue so I added some code to
check the fragment options. Personally I think we are probably okay
without it as the un-autenticated/un-verified nature of these labeling
protocols more or less requires either a trusted network/hosts.
If the community decides that this check is not required then I can
simply drop all of the changes in ip_fragment.c.
- Can you explain how module loading and module refcounting for these
modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
always safe to unload if the refcount is zero?)
Heh, not really :)
This is part of the not ready for submission qualifier I mentioned at
the top of my post. Honestly I'm not sure it makes sense to have this
code as a loadable module anyway I just used some of the module bits as
it was the first example of code that I saw in the kernel which would
call init/exit functions.
If people think that this code should be made into a fully
loadable/unloadable module then there is definitely more work to be done
in this area as I really haven't looked into it too deeply. However, if
people are okay with it not being a module then I will find a proper way
of doing initialization without using the module bits.
Sorry for the confusion, I forgot to mention it earlier.
- What about user APIs for setting and retrieving labels?
The NetLabel mechanism supports getting the labels off of a packet
directly or from the top most packet on the incoming socket queue. I
have left it up to the LSM to decide how to expose that functionality to
the user. In SELinux this is done by using the SO_PEERSEC option
similar to how you would do it if you were using the IPsec SA labeling.
It works by looking at the top most packet in the socket receive queue
for TCP and at the packet itself for UDP.
You can set/reset the label by calling the NetLabel function to set the
label of a socket; right now the label of outgoing packets is tightly
tied to the label of the socket from which they were sent. The NetLabel
code does support changing the label of a socket but I have not added
the code to SELinux to support that because I am not clear that is a
good thing to do from a SELinux point of view, currently the label is
set when the socket is created. However, should people decide this is a
good thing, one possibility would be to enable the SO_PEERSEC option for
setsockopt().
- What about labeling of kernel-generated packets?
Kernel generated packets which are created in response to an incoming
packet, i.e. ICMP errors, get the label of the packet which caused the
response. This seems to be correct from the draft's point of view as
well as several people on the LSM list.
There may be an issue with packets generated by the kernel directly and
not as a result of an incoming packet but I can't think of a case where
this would happen (although I suspect I am just not thinking hard
enough). Do you have a scenario in mind?
- Don't put #ifdef'd code into mainline code.
e.g. in net/ipv4/ip_fragment.c
+#ifdef CONFIG_NETLABEL_CIPSOV4
+ if (sopt-cipso) {
This needs to be a function which is compiled away as a static inline when
not selected. This stuff should have zero impact on the networking code
if not enabled.
Okay. I suspect this code will go away, but just for my own education
were you thinking of something like this?
static inline int my_func(void)
#ifdef CONFIG_NETLABEL_CIPSOV4
/* real stuff */
#else
/* compile away into a zero */
return 0;
#endif
}
... or something else?
- Try and add entries for security/selinux/nlmsgtab.c for the new Netlink
protocol.
- This does not follow normal kernel coding practices:
{snip}
- This kind of stuff should be removed before merging:
{snip}
Okay.
- Why does this module have a version number?
+ printk(KERN_INFO NetLabel: Initializing (v%s %s)\n,
+ NETLBL_VER_STR, NETLBL_VER_DATE);
The version number is there primarily to help signal possible
differences in the NetLabel netlink protocol.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Re: [RFC 0/4] NetLabel
On Fri, 26 May 2006, Paul Moore wrote: There may be an issue with packets generated by the kernel directly and not as a result of an incoming packet but I can't think of a case where this would happen (although I suspect I am just not thinking hard enough). Do you have a scenario in mind? There are several possibilities, I believe. The networking code would need to be audited to find them all. Okay. I suspect this code will go away, but just for my own education were you thinking of something like this? static inline int my_func(void) #ifdef CONFIG_NETLABEL_CIPSOV4 /* real stuff */ #else /* compile away into a zero */ return 0; #endif } ... or something else? No. You put the real function in a .c file and the dummy inline in a .h file. There are many examples of this in the kernel. - Why does this module have a version number? + printk(KERN_INFO NetLabel: Initializing (v%s %s)\n, + NETLBL_VER_STR, NETLBL_VER_DATE); The version number is there primarily to help signal possible differences in the NetLabel netlink protocol. How will this ever help anything? If you change that protocol, userspace applications will break, which is not acceptable. You can add versioning at the protocol level or via adding a new netlink family in the future, but existing apps cannot break and you need to maintain compatibility. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
Paul Moore wrote: James Morris wrote: On Thu, 25 May 2006, Paul Moore wrote: This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing trusted operating systems such as Trusted Solaris. A few initial comments. - Did you decide that you definitely need to verify labels on fragments? I can see the code's been added to do that, but wonder about a comment made during earlier discussion that mislabeled fragments could only come from a misbehaving trusted system. What is the threat model here? This is one part of the patch that I really don't have a strong feeling for either way. There was some concern on the LSM list that not checking the fragment options might be an issue so I added some code to check the fragment options. Personally I think we are probably okay without it as the un-autenticated/un-verified nature of these labeling protocols more or less requires either a trusted network/hosts. If the community decides that this check is not required then I can simply drop all of the changes in ip_fragment.c. If you state you are labeling session packets (tcp or udp), that would lead one to believe all packets are labeled (including fragments). Based on our past evaluations I don't think non-labeled fragments would make it through an evaluation if CIPSO/RIPSO were part of the TOE/security Target. - Can you explain how module loading and module refcounting for these modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it always safe to unload if the refcount is zero?) -- Thanks, Mike Mikel L. Matthews Chief Technology Officer Innovative Security Systems, Inc. (dba Argus Systems Group) 1809 Woodfield Dr. Savoy IL 61874 +1-217-355-6308 www.argus-systems.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
Mikel L. Matthews wrote: Paul Moore wrote: James Morris wrote: On Thu, 25 May 2006, Paul Moore wrote: This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing trusted operating systems such as Trusted Solaris. A few initial comments. - Did you decide that you definitely need to verify labels on fragments? I can see the code's been added to do that, but wonder about a comment made during earlier discussion that mislabeled fragments could only come from a misbehaving trusted system. What is the threat model here? This is one part of the patch that I really don't have a strong feeling for either way. There was some concern on the LSM list that not checking the fragment options might be an issue so I added some code to check the fragment options. Personally I think we are probably okay without it as the un-autenticated/un-verified nature of these labeling protocols more or less requires either a trusted network/hosts. If the community decides that this check is not required then I can simply drop all of the changes in ip_fragment.c. If you state you are labeling session packets (tcp or udp), that would lead one to believe all packets are labeled (including fragments). Based on our past evaluations I don't think non-labeled fragments would make it through an evaluation if CIPSO/RIPSO were part of the TOE/security Target. Outgoing fragment *should* be labeled correctly assuming the Linux base network stack does the right thing (I haven't tested this yet). The issue we are discussing here is what to do about incoming packets where the fragments are not consistently labeled. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
Same issue, I would drop them. Paul Moore wrote: Mikel L. Matthews wrote: Paul Moore wrote: James Morris wrote: Outgoing fragment *should* be labeled correctly assuming the Linux base network stack does the right thing (I haven't tested this yet). The issue we are discussing here is what to do about incoming packets where the fragments are not consistently labeled. -- Thanks, Mike Mikel L. Matthews Chief Technology Officer Innovative Security Systems, Inc. (dba Argus Systems Group) 1809 Woodfield Dr. Savoy IL 61874 +1-217-355-6308 www.argus-systems.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
James Morris wrote: On Fri, 26 May 2006, Paul Moore wrote: - Why does this module have a version number? + printk(KERN_INFO NetLabel: Initializing (v%s %s)\n, + NETLBL_VER_STR, NETLBL_VER_DATE); The version number is there primarily to help signal possible differences in the NetLabel netlink protocol. How will this ever help anything? If you change that protocol, userspace applications will break, which is not acceptable. You can add versioning at the protocol level or via adding a new netlink family in the future, but existing apps cannot break and you need to maintain compatibility. The NetLabel netlink protocol does have a version message which can be used to get the version. My main reason for doing this is not to signal changes to existing messages, i.e. break backward compatability, but to signal to user space applications that the kernel supports a newer protocol. The printk() above is just informative, if that is your main concern I can yank it. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
On Fri, 26 May 2006, Paul Moore wrote: The NetLabel netlink protocol does have a version message which can be used to get the version. My main reason for doing this is not to signal changes to existing messages, i.e. break backward compatability, but to signal to user space applications that the kernel supports a newer protocol. The printk() above is just informative, if that is your main concern I can yank it. Yes, please do. Linux kernel subsystems don't have versions, use the main kernel version if you need to. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/4] NetLabel
This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing trusted operating systems such as Trusted Solaris. I am posting the patch now not because I feel it is ready for inclusion into any of the main kernel trees but because it is usable and I would like to solicit comments from the community sooner rather than later. I know there has been at least one previous effort to get CIPSO support into the kernel and that was rejected. I have tried to take the feedback from that patch into consideration with this patch and create a new mechanism which treads as lightly as possible on the core networking stack. I have also worked to make the new patch LSM agnostic so that this code can be shared amongst multiple LSMs; while I am only providing a patch for SELinux at this point I do understand that there is at least one other LSM that is interested in making use of this new mechanism. I understand that there will probably need to be a lengthy review period due to the size and complexity of this patch. I also understand that my relative inexperience with submitting patches to the Linux kernel will not do much to help my cause but I appreciate your patience and any comments you may have. There is a more information as well as a basic userspace tool for configuration of the NetLabel subsystem here: * http://free.linux.hp.com/~pmoore/projects/linux_cipso Thanks. CREDITS |7 Documentation/00-INDEX|2 Documentation/netlabel/00-INDEX | 10 Documentation/netlabel/cipso_ipv4.txt | 48 Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt | 791 + Documentation/netlabel/introduction.txt | 44 Documentation/netlabel/lsm_interface.txt | 47 include/linux/ip.h|1 include/linux/netlink.h |1 include/net/cipso_ipv4.h | 179 + include/net/inet_sock.h |2 include/net/netlabel.h| 355 ++ net/Kconfig |2 net/Makefile |1 net/ipv4/Makefile |1 net/ipv4/cipso_ipv4.c | 1568 ++ net/ipv4/ip_fragment.c| 38 net/ipv4/ip_options.c | 19 net/netlabel/Kconfig | 47 net/netlabel/Makefile | 15 net/netlabel/netlabel_cipso_v4.c | 519 +++ net/netlabel/netlabel_cipso_v4.h | 185 + net/netlabel/netlabel_domainhash.c| 629 net/netlabel/netlabel_domainhash.h| 64 net/netlabel/netlabel_kapi.c | 374 ++ net/netlabel/netlabel_mgmt.c | 686 net/netlabel/netlabel_mgmt.h | 265 + net/netlabel/netlabel_unlabeled.c | 289 + net/netlabel/netlabel_unlabeled.h | 90 net/netlabel/netlabel_user.c | 166 + net/netlabel/netlabel_user.h | 42 security/selinux/hooks.c | 64 security/selinux/include/security.h |6 security/selinux/ss/ebitmap.c | 155 security/selinux/ss/ebitmap.h |6 security/selinux/ss/mls.c | 160 + security/selinux/ss/mls.h | 25 security/selinux/ss/services.c| 252 + security/selinux/xfrm.c | 22 39 files changed, 7156 insertions(+), 21 deletions(-) -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
Stephen Hemminger wrote: On Thu, 25 May 2006 16:06:01 -0400 Paul Moore [EMAIL PROTECTED] wrote: This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing trusted operating systems such as Trusted Solaris. I am posting the patch now not because I feel it is ready for inclusion into any of the main kernel trees but because it is usable and I would like to solicit comments from the community sooner rather than later. Maybe this would be easier and better done via existing netfilter infrastructure? I think this would be rather difficult on the outbound side as protocols like CIPSO and RIPSO add IP options to the packet. I may be wrong but I thought that adding to the size of the packet was a no-no in netfilter? Also, doesn't netfilter get the packet after the checksum has been calculated and the packet has gone through the xfrm infrastructure? -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
On Thu, 25 May 2006, Paul Moore wrote:
This patch introduces a new kernel feature designed to support labeled
networking protocols such as RIPSO and CIPSO. These protocols are required to
interoperate with existing trusted operating systems such as Trusted
Solaris.
A few initial comments.
- Did you decide that you definitely need to verify labels on fragments?
I can see the code's been added to do that, but wonder about a comment
made during earlier discussion that mislabeled fragments could only come
from a misbehaving trusted system. What is the threat model here?
- Can you explain how module loading and module refcounting for these
modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
always safe to unload if the refcount is zero?)
- What about user APIs for setting and retrieving labels?
- What about labeling of kernel-generated packets?
- Don't put #ifdef'd code into mainline code.
e.g. in net/ipv4/ip_fragment.c
+#ifdef CONFIG_NETLABEL_CIPSOV4
+ if (sopt-cipso) {
This needs to be a function which is compiled away as a static inline when
not selected. This stuff should have zero impact on the networking code
if not enabled.
- Try and add entries for security/selinux/nlmsgtab.c for the new Netlink
protocol.
- This does not follow normal kernel coding practices:
+ if (netlbl_netlink_init() != 0) {
+ netlbl_domhsh_exit();
+ return -ENOMEM;
This should be:
{
err = netlbl_netlink_init();
if (err)
goto err_domhsh;
...
err_domhsh:
netlbl_domhsh_exit();
return err;
}
i.e. a single error path when you have cleanups to perform, and
propagation of error codes.
- This kind of stuff should be removed before merging:
+static void __exit netlbl_exit(void)
+{
+ printk(KERN_INFO NetLabel: Exiting\n);
+int netlbl_netlink_init(void)
+{
+ BUG_ON(netlbl_nl);
+int netlbl_netlink_exit(void)
+{
+ BUG_ON(!netlbl_nl);
Should the above two be marked __init and __exit? And why does the last
one return an int when the only possible return value is zero? (it needs
to return void).
- Why does this module have a version number?
+ printk(KERN_INFO NetLabel: Initializing (v%s %s)\n,
+ NETLBL_VER_STR, NETLBL_VER_DATE);
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
