David P. Quigley wrote:
> On Wed, 2009-12-02 at 19:37 -0800, Casey Schaufler wrote:
>
>> David P. Quigley wrote:
>>
>>> On Tue, 2009-12-01 at 21:43 -0800, Casey Schaufler wrote:
>>>
>>>
>>>>> also what happens when other transport protocols come around like sctp
>>>>> for instance. now we need another 65k files for this as well.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Ok, so it would appear that the notion of a fully populated
>>>> portfs has sufficient stumbling blocks to make it a non-starter.
>>>>
>>>> A dynamically maintained version, with default values for unallocated
>>>> ports and memory based xattrs stored on request would still be viable.
>>>>
>>>> Yes, it's more work. I'd rather see a generally useful scheme than an
>>>> SELinux specific one, if for no other reason than it makes the general
>>>> case harder to sell later on.
>>>>
>>>>
>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>> You still need to address my issue with port ranges.
>>>
>> Why does the notions of port ranges make any sense at all? That
>> sounds an awful lot like name based access control from here, and
>> we know the evils of name based access controls. (smiley here)
>>
>
> Because if I want to have set of ports labeled reserved_port_t or
> no_access_port_t and have a neverallow rule for no_access_port_t I have
> to iterate through every file that I want to have that. That is why a
> port range is useful.
If you're going to treat ports as named objects (things
that require labels) it seems as if the interfaces for
dealing with them ought not make it easy to make mistakes.
If you really care you don't want people doing things like
set ports 1-9999 some_port_t
set ports 77,802 another_port_t
and don't even think of trying to say that isn't what is
going to happen.
> It sound nothing what so ever like name based
> access control.
>
How is "all ports named 1-1024" different from
"all files named /etc/net*" ?
>
>>> Also I don't find
>>> this interface generically useful when you have to have intimate
>>> knowledge of the LSM to know what the correct xattrs to set are. You
>>> pointed it out yourself that Smack handles port labeling differently
>>> than SELinux
>>>
>> Nope. Smack does not label ports. Ports are not policy components in
>> Smack. I pointed out that Smack treats sockets differently than SELinux.
>> I did so to address your issue with multiple xattrs on an object. I
>> pointed out that it is easy to do.
>>
>>
>>> so to try to shoe horn every LSM that labels ports into a
>>> filesystem interface where the user has to know LSM specific xattrs to
>>> set doesn't seem generic to me.
>>>
>>>
>> The xattr interface is generic. Yes, you have to know the name of
>> the attribute as well as the value it should have and yes that will
>> differ between LSMs.
>>
>>
>>> Dave
>>>
>> Now I'm glad the notion has been considered, and I can understand
>> if it seems like too much work or if you just don't see it as a good
>> idea.
>>
>> How about making it a part of the labeled networking code then?
>> That would seem to be a more focused approach that would also,
>> and perhaps better, address the generality concern.
>>
>
> I'd consider talking to Paul Moore about it and getting his input then
> as I'm just a filesystem guy :)
>
>
Paul responded in the negative, and I respect his judgement, even
on the occasion where we disagree.
Looks as if y'all are happier with a iptables-ish interface
than a filesystem-ish interface. Enjoy.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
