[RFC 0/4] NetLabel

[RFC 0/4] NetLabel

[Paul Moore]

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

Re: [RFC 0/4] NetLabel

[Stephen Hemminger]

On Thu, 25 May 2006 16:06:01 -0400
Paul Moore <paul.moore@hp.com> 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.
> 
> 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
> 

Maybe this would be easier and better done via existing netfilter infrastructure?

Re: [RFC 0/4] NetLabel

[Paul Moore]

Stephen Hemminger wrote:
> On Thu, 25 May 2006 16:06:01 -0400
> Paul Moore <paul.moore@hp.com> 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

Re: [RFC 0/4] NetLabel

[James Morris]

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
<jmorris@namei.org>

Re: [RFC 0/4] NetLabel

[Paul Moore]

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

Re: [RFC 0/4] NetLabel

[James Morris]

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
<jmorris@namei.org>

Re: [RFC 0/4] NetLabel

[Paul Moore]

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

Re: [RFC 0/4] NetLabel

[James Morris]

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
<jmorris@namei.org>

Re: [RFC 0/4] NetLabel

[Mikel L. Matthews]

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

Re: [RFC 0/4] NetLabel

[Paul Moore]

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

Re: [RFC 0/4] NetLabel

[Mikel L. Matthews]

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