Re: connected_stream_socket_perms

[Russell Coker <russell@coker.com.au>]

I don't even know where to start with this. What are the aims here? What access is reasonable and necessary?

The one assumption I think we can start from is that current policy is not a good guide to what is required. Probably all current policy is bad in this regard.

On 11 January 2019 12:23:21 pm AEDT, Chris PeBenito <pebenito@ieee.org> wrote:
>On 1/10/19 5:51 AM, Russell Coker wrote:
>> define(`rw_socket_perms', `{ ioctl read getattr write setattr append
>bind
>> connect getopt setopt shutdown }')
>> 
>> define(`connected_socket_perms', `{ create ioctl read getattr write
>setattr
>> append bind getopt setopt shutdown }')
>> 
>> The difference between these 2 is that connected_socket_perms
>includes create
>> while rw_socket_perms has connect.  Why doesn't rw_socket_perms have
>create?
>> Or if we are saying "rw_socket_perms only means reading and writing"
>then why
>> does it have connect?
>> 
>> Does this all make sense?
>> 
>> I expect that a lot of policy has been written based on using
>whichever of
>> those macros seems to match an audit2allow rule and vaguely match the
>concept
>> of what someone imagines the program in question is doing.
>> 
>> Would it make sense to have another macro defined to { ioctl read
>getattr write
>> setattr append bind getopt setopt shutdown } so that there can be a
>more
>> obvious progression of which macro is a superset of which other
>macro?
>
>Those lines are ancient (2005).  I'm open to reveisions.  I'm
>definitely 
>eager for better clarity and consistency.

-- 
Sent from my Huawei Mate 9 with K-9 Mail.