[SEPOL][SEMANAGE] Nodecon Support: Try 1

[SEPOL][SEMANAGE] Nodecon Support: Try 1

[Ivan Gyurdiev]

[-- Attachment #1: Type: text/plain, Size: 3254 bytes --]

Hi, this patch is here to gather feedback, as I wouldn't want to mess up 
Joshua's pending merge - I will resync after that.
I also suspect I'll have to do some changes to the patch. Note: patch 
also is based on top of the PyList swig file, since that patch hasn't 
been rejected or accepted yet. If you'd like me to rebase on the 
previous swig file, that's not very hard to do.

The patch implements nodecon support in libsepol and libsemanage (but 
not yet in the semanage utility).
Important points:

1) The record - represents a nodecon entry as (addr, addr_sz, mask, 
mask_sz, proto, con), where addr and mask are byte arrays. The key is 
(addr, addr_sz, mask, mask_sz, proto). This is a bit different from 
other records, where we've worked with strings, but I think it's the 
better approach. I provide get and set functions for both name strings 
(get/set_addr, get/set_mask), and byte arrays (get/set_addr_bytes, 
get/set_mask_bytes). When working with strings, pton/ntop are used to 
convert to byte arrays, which are the record's internal representation - 
more compact, and allows comparison of two addresses. This means the 
protocol is passed into set_addr() and set_mask() to control which 
function is used (see below on the protocol being made explicit).

2) The sepol support - does not divide records into ipv4/6. It handles 
both in the same set of functions (exists, query, modify, count, 
iterate). The protocol is used to disambiguate. Count and iterate loop 
over both ipv4 and 6 addresses.

3) The semanage file support - I've modified the format of a nodecon 
entry for the semanage internal format to this:
nodecon <proto> <addr> <mask> <con>, where proto = ipv4 or ipv6. I 
prefer this approach, since I think the protocol should be explicitly 
specified, instead of guessing what it is based on format. This seems 
more correct to me, and makes the code easier. As with other semanage 
files, arbitrary whitespace and multiple lines are allowed.

4) Comparison... is kept simple, following precedent set by ports. Match 
if (addr, mask) match exactly, otherwise use some sort of ordering 
scheme to return either -1 or 1 consistently.

Unresolved issues:
==============
1) Joshua raised the point that set_addr and set_addr_bytes do the same 
thing, so only set_addr_bytes should exist, and a converter function 
should be exposed to convert string -> bytes. This is easy to do, but I 
favor the current approach - exposing a converter function makes it more 
difficult for the client to use the API.

2) The get_bytes, and set_bytes work in byte arrays. An alternative 
approach is to use integer arrays. I have no strong preference on this, 
but it seems that byte arrays are more general. I'm not sure what would 
be more useful to a client.

3) Related to 2 is the issue of byte order. get_bytes and set_bytes 
currently use network byte order. Should they be changed to use host 
byte order? If so, should the byte order be changed with respect to the 
whole array, or by integer (i.e. flip all 16 bytes, or flip in groups of 4).

4) Ordering by netmask specificity... is not yet implemented. This 
requires adding insertion sort support for arbitrary records to the list 
dbase. I'd rather do it in a separate patch.

[-- Attachment #2: libsepol.semanage.nodecon.diff.bz2 --]
[-- Type: application/x-bzip, Size: 11941 bytes --]

Re: [SEPOL][SEMANAGE] Nodecon Support: Try 1

[Ivan Gyurdiev]

>  When working with strings, pton/ntop are used to convert to byte 
> arrays, which are the record's internal representation - more compact, 
> and allows comparison of two addresses. This means the protocol is 
> passed into set_addr() and set_mask() to control which function is 
> used (see below on the protocol being made explicit).
s/"which function"/"which namespace"/ i.e. AF_INET or AF_INET6.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [SEPOL][SEMANAGE] Nodecon Support: Try 1

[Ivan Gyurdiev]

[-- Attachment #1: Type: text/plain, Size: 56 bytes --]

Attached is a resync of the same patch to current CVS.


[-- Attachment #2: libsemanage.sepol.nodecon.diff.bz2 --]
[-- Type: application/x-bzip, Size: 11752 bytes --]

Re: [SEPOL][SEMANAGE] Nodecon Support: Try 1

[Ivan Gyurdiev]

> Attached is a resync of the same patch to current CVS.
Ok, this patch needs more work, I guess.

According to Chad Hanson (on IRC) the kernel reorders by netmask, which 
will not work with this patch.
If this is the case, then this problem is equivalent to the issue with 
ports - namely, the strategy to replace exact key match, and prepend 
everything else in front does not work, and creates problems. The code 
needs to be smarter on updates - needs to edit port ranges and nodecon 
entries that are overridden locally, and make the appropriate changes.

Other comments by Chad:
- no preference on byte order  - should probably follow policy 
convention (network byte order?)
- byte arrays are better than integer ones


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [SEPOL][SEMANAGE] Nodecon Support: Try 1

[Stephen Smalley]

On Wed, 2006-02-08 at 03:21 -0500, Ivan Gyurdiev wrote:
> Attached is a resync of the same patch to current CVS.

Merged as of libsepol 1.11.15 and libsemanage 1.5.24.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [SEPOL][SEMANAGE] Nodecon Support: Try 1

[Chad Hanson]

>> Attached is a resync of the same patch to current CVS.
>Ok, this patch needs more work, I guess.

>According to Chad Hanson (on IRC) the kernel reorders by netmask, which 
>will not work with this patch.

I guess I need to correct myself, that checkpolicy, not the kernel orders
the nodecon rules.

http://marc.theaimsgroup.com/?l=selinux&m=109906728301734&w=2
http://marc.theaimsgroup.com/?l=selinux&m=109968743026327&w=2
http://cvs.sourceforge.net/viewcvs.py/selinux/nsa/selinux-usr/checkpolicy/po
licy_parse.y?r1=1.24&r2=1.25

>If this is the case, then this problem is equivalent to the issue with 
>ports - namely, the strategy to replace exact key match, and prepend 
>everything else in front does not work, and creates problems. The code 
>needs to be smarter on updates - needs to edit port ranges and nodecon 
>entries that are overridden locally, and make the appropriate changes.
>

The ordering by checkpolicy allows the nodecon rules to be unordered, even
though it may be confusing to an administrator. A network rule prepended to
a list won't have precendence to a exact host rule.

>Other comments by Chad:
>- no preference on byte order  - should probably follow policy 
>convention (network byte order?)
>- byte arrays are better than integer ones

Correct

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [SEPOL][SEMANAGE] Nodecon Support: Try 1

[Ivan Gyurdiev]

> I guess I need to correct myself, that checkpolicy, not the kernel orders
> the nodecon rules.
>
> http://marc.theaimsgroup.com/?l=selinux&m=109906728301734&w=2
> http://marc.theaimsgroup.com/?l=selinux&m=109968743026327&w=2
> http://cvs.sourceforge.net/viewcvs.py/selinux/nsa/selinux-usr/checkpolicy/po
> licy_parse.y?r1=1.24&r2=1.25
>   
Ah, this makes all the difference... then the original plan makes sense, 
and the patch should work, once ordering is added in the local case. I 
should be able to make a nodecon spec take precedence by placing it in 
front of the ocontext_t list, correct?

The ports issue I described stands anyway, list() and iterate() show 
overlapping ranges, and that will be an issue for nodes as well.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.