Hi KaiGai,
On Tue, 2007-11-06 at 19:00 +0900, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> > We have to set up several SPD entries with a security context
> > to apply labeled IPsec, like as:
> >
> > spdadd 192.168.1.10 192.168.1.20 any
> > -ctx 1 1 "system_u:object_r:unconfined_t:s0"
> > -P in ipsec esp/transport//require;
> >
> > What is the most appropriate context to be specified?
> > Or, is the security policy to be modified?
> >
I think you should be able to use default spd security
context, ipsec_spd_t.
> > In the current reference policy, several domain have permissions
> > of association class for 'self' or 'unlabeled_t'.
> > However, it can cause a matter when 'unconfined_t' processes tries
> > to connect 'postgresql_t' process running on another host via labeled
> > IPsec, for instance.
> >
> > We can add additional permissions to avoid the matter, as follows:
> > allow postgresql_t unconfined_t : association { ... };
> >
> > But IMO it makes a bit confusable to apply process's domain as
> > a type of SPD entries, like unconfined_t and so on.
> >
> > I prefer the following description to separate subject and object.
> > allow postgresql_t postgresql_spd_t : association { ... };
> > allow unconfined_t postgresql_spd_t : association { ... };
>
> In policy/modules/system/ipsec.te, ipsec_spd_t is defined as a default
> type for IPSEC SPD entries, as follows:
>
> # Default type for IPSEC SPD entries
> type ipsec_spd_t;
> :
> allow racoon_t ipsec_spd_t:association setcontext;
> :
> allow setkey_t ipsec_spd_t:association setcontext;
> :
>
> However, setkey_t and racoon_t are the all which have any permission
> on ipsec_spd_t.
> Is it more preferable than applying a domain as a type of SPD entries?
>
This permission allows only racoon and setkey to actually set the
security context, ipsec_spd_t within SPD or SA entry. This controls
who can add or delete SPD and SA entries. Thus no other application is
currently allowed to do this.
We decided to include a default context for SPD entries. Sysadmins can
add more, but additional policy is required for each context you set
in SPD. Below will explain why.
Labeled ipsec authorizes; who can create and delete SPD entries,
whether or not flow can use SPD entry; and if so
the SAs that can be generated by an SPD entry, and the SAs that
can send and receive on a particular flow.
A better explanation is a quick step through process.
- Each traffic stream you want secured will have an SPD entry created by
sysadm (setcontext).
- An app such as telnet results in a packet being generated. The flow
(or you could say session's traffic stream) must be authorized to use
the SPD entry (POLMATCH). Last I recall, flow's security context was
that of socket. So far example, let's say flow's security context is
telnet_t. Thus is telnet (telnet_t) authorized to use ipsec
policy (ipsec_spd_t)
- Once flow is authorized to use SPD entry, it looks for an SA. If
none, creates one. I believe SA's security context is that of socket
which generated packet, thus it will be telnet_t.
Check is made that authorizes whether the SA can send on the
flow using the SPD entry (SENDTO).
Thus networking apps need to be able to POLMATCH with ipsec policy and
resulting SAs need to be able to SENDTO on the flow.
I don't have current selinux policy source and I don't remember the
names and details of files, etc... but I think everything in
"domain" is authorized to POLMATCH to ipsec_spd_t and everything
in "domain" is authorized to SENDTO and RECVFROM for ASSOCIATION.
So, if you or a sysadm want to create another security context
for SPD entries, other than the default. You will also need selinux
policy to:
- authorize racoon and setkey to set this new security context
within an ipsec policy or association (SETCONTEXT).
- authorize who can POLMATCH with the new spd entry.
- authorize who can SENDTO and RECVFROM on the flow.
( I think there is an interface, ipsec_labeled, for an example
of latter two authorizations.)
I am not sure what your requirements are... I don't have policy
source so not sure if unconfined_t is in "domain" are perhaps needs
ipsec_labeled()... but I am thinking you should be able to use default
SPD security context...
Sorry, if this email got really long, but once I started with an
explanation I could not stop. I don't even know if this helps,
so let me know how I can help.
regards,
Joy
--
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.
