From: dwalsh@redhat.com (Daniel J Walsh)
Date: Mon, 20 Oct 2008 14:57:49 -0400
Subject: [refpolicy] request for comments: policy for nufw and nuauth
In-Reply-To: <20081020162358.GB30642@piche.inl.fr>
References: <20081020162358.GB30642@piche.inl.fr>
Message-ID: <48FCD4AD.2090606@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Pierre Chifflier wrote:
> Hi,
> 
> I have tried to write policy modules for 2 applications I'm maintaining
> (and contributing): nufw and nuauth.
> 
> Since this is my first policies, it would be great to have some feedback
> on the contents. I would like to propose these modules for integration
> in the standard policy, if possible.
> 
> 
> If you don't know nufw or nuauth, a few words of description:
> 
> - nufw use the NFQUEUE target of iptables (and so, a nfnetlink socket)
>   to receive packets in userspace. It will send the packets using a TLS
>   connection to nuauth, the user authenticating daemon, wait for a
>   decision, and apply it.
> This is the simplest of the 2 daemons.
> 
> - nuauth is the authentication daemon. It has several roles:
>   - wait for connections from nufw daemons, receive packets, apply ACL
>     (see later), and return verdict
>   - wait for connections from nutcpc (clients), validate login/pass
>     using PAM, and communicate with them
>   - check ACL in a plain text file, or a LDAP server
>   - log messages to syslog, MySQL, or PostgreSQL (depending on the
>     loaded modules, and the configuration).
>   - nuauth and the clients use SASL for authentication, and TLS for all
>     communications
> The policy module for nuauth is not complete, I'm still working on it.
> 
> Any help/comment would be appreciated !
> 
> Thanks,
> Pierre
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
You should never (almost never) have a gen_requires interface in a te file.

You should use interfaces.

audit2allow -R

will attempt to find the correct interface for the AVC that was generated.

        type nufw_etc_t;
        type nufw_port_t;

Should have interfaces defined for them to be used by other domains.

files_pid_file(nuauth_var_run_t)
allow nuauth_t nuauth_var_run_t:dir { search write remove_name add_name };
allow nuauth_t nuauth_var_run_t:file { create write read getattr unlink };
allow nuauth_t nuauth_var_run_t:sock_file { unlink create write };


Should probably be something like

manage_files_pattern(nuauth_t, nuauth_var_run_t, nuauth_var_run_t)
manage_sock_files_pattern(nuauth_t, nuauth_var_run_t, nuauth_var_run_t)

> allow nuauth_t etc_t:file { getattr read };
Should be
files_read_etc(nuauth_t)


# allow clients to connect
allow unconfined_t nuauth_port_t:tcp_socket recv_msg;
allow unconfined_t nuauth_port_t:tcp_socket name_connect;

Not necessary. unconfined_t already can

>allow nuauth_t bin_t:dir search;
corecmd_search_bin(nuauth_t)

> allow nuauth_t postgresql_port_t:tcp_socket { name_connect send_msg
recv_msg };

Look for corenetwork calls.