security context for SPD entries of labeled IPsec

Quoted 4 lines

There are 2 aspects:

1. IPsec policy matching discussed above:
allow domain-that-should-use-labeled-ipsec

ipsec_spd_t:association { polmatch };

Quoted 5 lines

2. Use of IPsec associations themselves:

For sending:
allow

domain-that-should-use-labeled-ipsec-to-label-its-packets self:association { sendto };

Quoted 3 lines

For receiving:
allow domain-that-should-received-from-peer peer-domain

self:association { recvfrom };

When we consider the case unconfined_t process tries to communicate with a postgresql_t
process running on another host via labeled IPsec, the following policy will be needed.

1. allow unconfined_t ipsec_spd_t : association { polmatch };

2s. allow unconfined_t self : association { sendto };

2r. allow postgresql_t unconfined_t : association { recvfrom };

Is it correct?

<snip>

Quoted 13 lines

Quoted 4 lines

There are 2 aspects:

1. IPsec policy matching discussed above:
allow domain-that-should-use-labeled-ipsec

ipsec_spd_t:association { polmatch };

Quoted 4 lines

2. Use of IPsec associations themselves:

For sending:
allow

domain-that-should-use-labeled-ipsec-to-label-its-packets self:association { sendto };

Quoted 2 lines

For receiving:
allow domain-that-should-received-from-peer peer-domain

Quoted 8 lines

self:association { recvfrom };

When we consider the case unconfined_t process tries to communicate with a postgresql_t
process running on another host via labeled IPsec, the following policy will be needed.

1. allow unconfined_t ipsec_spd_t : association { polmatch };

Also, allow postgresql_t ipsec_spd_t : association { polmatch }; since the incoming packet labeled postgresql_t should be checked against IPsec policy (SPD) rule labeled with ipsec_spd_t.

Quoted 1 line

2s. allow unconfined_t self : association { sendto };

OK.

Quoted 1 line

2r. allow postgresql_t unconfined_t : association { recvfrom };

This should actually be:

allow unconfined_t postgresql_t : association { recvfrom };

since it would be the unconfined_t socket that would be receiving a packet using the postgresql_t association.

Quoted 2 lines

Is it correct?

<snip>

--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.

Quoted 22 lines · KaiGai Kohei

Quoted 5 lines · Christopher J. PeBenito

Quoted 4 lines · KaiGai Kohei

Did you notice that a patch was attached in my previous posting? Because I put a description about this patch on the bottom of the message, it might be easy to overlook it.

Quoted 7 lines

Quoted 2 lines

Could you review it? It is desirable for me to enable to communicate between different domains via labeled ipsec.

I committed an alternate version,

http://oss.tresys.com/projects/refpolicy/changeset/2499
http://oss.tresys.com/projects/refpolicy/changeset/2500

Thanks to apply them,

However, it does not contain any permissions which allows users and daemons domain to communicate via labeled ipsec.

In my patch, these permissions were allowed at system/init.if and system/userdomain.if. Do you consider these permissions should not be allowed implicitly inside these interfaces?

Quoted 3 lines

Currently, it is not enough for SE-PostgreSQL to communicate peers using a SPD with default security context. They are requiring a bit more permissions.

I reject the blanket permissions that you had in your previous patch.

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

Quoted 23 lines · Christopher J. PeBenito

Quoted 22 lines · KaiGai Kohei

Quoted 5 lines · Christopher J. PeBenito

Quoted 4 lines · KaiGai Kohei

Did you notice that a patch was attached in my previous posting? Because I put a description about this patch on the bottom of the message, it might be easy to overlook it.

Quoted 7 lines

Quoted 2 lines

Could you review it? It is desirable for me to enable to communicate between different domains via labeled ipsec.

I committed an alternate version,

http://oss.tresys.com/projects/refpolicy/changeset/2499
http://oss.tresys.com/projects/refpolicy/changeset/2500

Thanks to apply them,

However, it does not contain any permissions which allows users and daemons domain to communicate via labeled ipsec.

In my patch, these permissions were allowed at system/init.if and system/userdomain.if. Do you consider these permissions should not be allowed implicitly inside these interfaces?

Quoted 5 lines

Quoted 3 lines

Currently, it is not enough for SE-PostgreSQL to communicate peers using a SPD with default security context. They are requiring a bit more permissions.

I reject the blanket permissions that you had in your previous patch.

OK, I can agree.

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Quoted 2 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 9 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 5 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

Quoted 4 lines

Quoted 2 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Quoted 16 lines

Quoted 9 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 7 lines

Quoted 5 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and integrate them with the upcaming flow control checks in the future kernel. However, a rule of "allow <domain> self : association {sendto}" will be necessary for the backward compatibility.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

Quoted 5 lines

Quoted 2 lines

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Yes. It seems like a lot, but if you think about it, there are already the base networking rules in the policy. This actually gives more of an opportunity to abstract the rules, so you get something like

interface postgresql_tcp_connect()

	corenet_tcp_sendrecv_postgresql_port($1)
	corenet_tcp_connect_postgresql_port($1)
	corenet_sendrecv_postgresql_client_packets($1)
	# labeled ipsec and (future) TE netlabel
	allow $1 postgresql_t:{ association tcp_socket } recvfrom;

	# compat labeled ipsec rule
	allow $1 self:association sendto;

and then even the labeled networking part could be put into a policy pattern.

Quoted 8 lines

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

Quoted 2 lines

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

I'm hesitant to add permissions like this as any domain that networks can have labeled networking. At best it seems like a stopgap measure until interfaces like the example above are in place.

Quoted 13 lines

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Yes. It seems like a lot, but if you think about it, there are already the base networking rules in the policy. This actually gives more of an opportunity to abstract the rules, so you get something like

Quoted 6 lines

interface postgresql_tcp_connect()

	corenet_tcp_sendrecv_postgresql_port($1)
	corenet_tcp_connect_postgresql_port($1)
	corenet_sendrecv_postgresql_client_packets($1)
	# labeled ipsec and (future) TE netlabel
	allow $1 postgresql_t:{ association tcp_socket } recvfrom;

Is it necessary to add "allow postgresql_t $1 : association recvfrom" ? (It's unclear for me, whether tcp_socket should be also, or not.)

$1 domain can receive replies from postgresql_t, but postgresql_t cannot receive messages from $1 domain.

Quoted 5 lines

	# compat labeled ipsec rule
	allow $1 self:association sendto;

and then even the labeled networking part could be put into a policy pattern.

What does it means policy pattern?

It's a bit unclear for me whether you intend to make a new template interface like the one defined at kernel/corenetwork.if.m4, or make a new interface for each daemon domains.

Quoted 8 lines

Quoted 8 lines

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

Quoted 6 lines

Quoted 2 lines

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

I'm hesitant to add permissions like this as any domain that networks can have labeled networking. At best it seems like a stopgap measure until interfaces like the example above are in place.

OK, I understood it.

Is it same for the unconfined_domain_type? They can receive messages from any domain, but the peer domain without unconfined_domain_type cannot receive messages from unconfined_domain_type.

Quoted 6 lines

Quoted 5 lines

	# compat labeled ipsec rule
	allow $1 self:association sendto;

and then even the labeled networking part could be put into a policy pattern.

What does it means policy pattern?

Its a support macro. See support/file_patterns.spt for file access patterns.

Quoted 3 lines

It's a bit unclear for me whether you intend to make a new template interface like the one defined at kernel/corenetwork.if.m4, or make a new interface for each daemon domains.

Each of the daemons would need it.

Quoted 3 lines

Is it same for the unconfined_domain_type? They can receive messages from any domain, but the peer domain without unconfined_domain_type cannot receive messages from unconfined_domain_type.

Good question. I'm not sure.

The attached patch provides the followins features:
- Two new policy pattern "labeled_(tcp|udp)_pattern" are added
- The postgresql_tcp_connect interface is revised to allow a domain to communicate with postgresql_t.
- postgresql_t can communicate others via default SPD.
- An obvious permission of "$1 self association:{sendto}" is allowed to any domain using ipsec_spd_t.
- Any user-domain using core-networks can communicate others via default SPD.
- Any user-domain can communicate postgresql_t via labeled networks.

Quoted 10 lines · KaiGai Kohei

The attached patch provides the followins features:
- Two new policy pattern "labeled_(tcp|udp)_pattern" are added
- The postgresql_tcp_connect interface is revised to allow a domain to communicate with postgresql_t.
- postgresql_t can communicate others via default SPD.
- An obvious permission of "$1 self association:{sendto}" is allowed to any domain using ipsec_spd_t.
- Any user-domain using core-networks can communicate others via default SPD.
- Any user-domain can communicate postgresql_t via labeled networks.

Merged [1], but I made some changes. I created corenetwork interfaces to use instead of the patterns, so the current MLS-only netlabel case can be handled too. I also updated the domain module to use the interfaces.

The thing that makes me a little nervous, which I didn't realize at first, is if you use non-labeled networking, the peer policy will still be needed, since the corenet connect/sendrecv calls are abstracted into the interface. Consider the non-labeled case for apache. The httpd_can_network_connect_db tunable won't work for postgresql, if the postgresql module isn't in the apache server's policy. Whats worse is, to make it work, you need to bring in the entire postgresql policy, even though you only need one type, and only need the recvfrom rules.

[1] http://oss.tresys.com/projects/refpolicy/changeset/2531

Quoted 14 lines

Merged [1], but I made some changes. I created corenetwork interfaces to use instead of the patterns, so the current MLS-only netlabel case can be handled too. I also updated the domain module to use the interfaces.

The thing that makes me a little nervous, which I didn't realize at first, is if you use non-labeled networking, the peer policy will still be needed, since the corenet connect/sendrecv calls are abstracted into the interface. Consider the non-labeled case for apache. The httpd_can_network_connect_db tunable won't work for postgresql, if the postgresql module isn't in the apache server's policy. Whats worse is, to make it work, you need to bring in the entire postgresql policy, even though you only need one type, and only need the recvfrom rules.

Quoted 1 line

[1] http://oss.tresys.com/projects/refpolicy/changeset/2531

I've considered to resolve the matter for a while, but I could not get any good idea. I think the most appropriate way is to separate corenet part from labeled networking part again, and to put corenet sendrecv pattern and an interface optionally to communicate via labeled networking.

I also considered a method to utilize the second argument of the "optional_policy" macro, but it seemed to me a bit ugly more.

How do you think the idea to revert apache.te and create a new interface to communicate via labeled networking only?

Quoted 14 lines

Quoted 14 lines

Merged [1], but I made some changes. I created corenetwork interfaces to use instead of the patterns, so the current MLS-only netlabel case can be handled too. I also updated the domain module to use the interfaces.

The thing that makes me a little nervous, which I didn't realize at first, is if you use non-labeled networking, the peer policy will still be needed, since the corenet connect/sendrecv calls are abstracted into the interface. Consider the non-labeled case for apache. The httpd_can_network_connect_db tunable won't work for postgresql, if the postgresql module isn't in the apache server's policy. Whats worse is, to make it work, you need to bring in the entire postgresql policy, even though you only need one type, and only need the recvfrom rules.

Quoted 1 line

Quoted 1 line

[1] http://oss.tresys.com/projects/refpolicy/changeset/2531

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Merged [1], but I made some changes. I created corenetwork interfaces to use instead of the patterns, so the current MLS-only netlabel case can be handled too. I also updated the domain module to use the interfaces.

The thing that makes me a little nervous, which I didn't realize at first, is if you use non-labeled networking, the peer policy will still be needed, since the corenet connect/sendrecv calls are abstracted into the interface. Consider the non-labeled case for apache. The httpd_can_network_connect_db tunable won't work for postgresql, if the postgresql module isn't in the apache server's policy. Whats worse is, to make it work, you need to bring in the entire postgresql policy, even though you only need one type, and only need the recvfrom rules.

Quoted 1 line

Quoted 1 line

Quoted 1 line

[1] http://oss.tresys.com/projects/refpolicy/changeset/2531

Chris, what is the current status of my patch submitted previously?

You pointed out that undeprecating postgresql_tcp_connect() to allow permissions for labeled and traditional networks can make unneeded dependency.

The attached patch reverts postgresql_tcp_connect() and related part, and puts corenet_tcp_recvfrom_labeled() and ipsec_match_default_spd() within optional_policy block, if necessary.
It enables any userdomain to communicate PostgreSQL/MySQL/SSHd via labeled networking, at first.
However, I believe we can apply this method for other domains also.

Quoted 21 lines · Kohei KaiGai

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Merged [1], but I made some changes. I created corenetwork interfaces to use instead of the patterns, so the current MLS-only netlabel case can be handled too. I also updated the domain module to use the interfaces.

The thing that makes me a little nervous, which I didn't realize at first, is if you use non-labeled networking, the peer policy will still be needed, since the corenet connect/sendrecv calls are abstracted into the interface. Consider the non-labeled case for apache. The httpd_can_network_connect_db tunable won't work for postgresql, if the postgresql module isn't in the apache server's policy. Whats worse is, to make it work, you need to bring in the entire postgresql policy, even though you only need one type, and only need the recvfrom rules.

Quoted 1 line

Quoted 1 line

Quoted 1 line

[1] http://oss.tresys.com/projects/refpolicy/changeset/2531

Chris, what is the current status of my patch submitted previously?

You pointed out that undeprecating postgresql_tcp_connect() to allow permissions for labeled and traditional networks can make unneeded dependency.

Quoted 6 lines

The attached patch reverts postgresql_tcp_connect() and related part, and puts corenet_tcp_recvfrom_labeled() and ipsec_match_default_spd() within optional_policy block, if necessary.
It enables any userdomain to communicate PostgreSQL/MySQL/SSHd via labeled networking, at first.
However, I believe we can apply this method for other domains also.

The use of types outside their modules is not acceptable, for example:

+ corenet_tcp_recvfrom_labeled(httpd_t,postgresql_t)

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

Quoted 14 lines · Paul Moore

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 8 lines

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Chris, is it suitable for refpolicy framework?

Quoted 2 lines · Kohei KaiGai

Quoted 1 line · Paul Moore

On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:

Quoted 13 lines

Quoted 13 lines

Quoted 13 lines

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

Quoted 4 lines

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

If this approach is approved by everyone else, I think we would want to add similar interfaces to all of the network facing daemons in the policy. I know it's a lot of work but it's the right thing to do.

Quoted 14 lines · Paul Moore

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 8 lines

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Chris, is it suitable for refpolicy framework?

Quoted 29 lines · Kohei KaiGai

Quoted 14 lines · Paul Moore

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 7 lines

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Quoted 1 line

Chris, is it suitable for refpolicy framework?

The only issue I have with it would just be the interface naming; probably something like mysql_tcp_recvfrom() would be better.

Quoted 25 lines · Christopher J. PeBenito

Quoted 24 lines · Kohei KaiGai

Quoted 14 lines · Paul Moore

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 7 lines

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

Quoted 8 lines

Quoted 6 lines

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Chris, is it suitable for refpolicy framework?

The only issue I have with it would just be the interface naming; probably something like mysql_tcp_recvfrom() would be better.

I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means permissions related to labeled networking, or not.

What do you think the following ideas?
- something_labeled_recvfrom(domain)
or
- something_labeled_tcp_recvfrom(domain)

Thanks,

Quoted 37 lines · Kohei KaiGai

Quoted 25 lines · Christopher J. PeBenito

Quoted 24 lines · Kohei KaiGai

Quoted 14 lines · Paul Moore

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 7 lines

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

Quoted 8 lines

Quoted 6 lines

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Chris, is it suitable for refpolicy framework?

The only issue I have with it would just be the interface naming; probably something like mysql_tcp_recvfrom() would be better.

I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means permissions related to labeled networking, or not.

Quoted 6 lines

What do you think the following ideas?
- something_labeled_recvfrom(domain)
or
- something_labeled_tcp_recvfrom(domain)

Thanks,

Oops, I found out this topic has not been progressed for a long time.

An interface of corenet_*_recvfrom_labeled(dom1, dom2) is provided in the latest policy, but nobody uses it except for a few cases like:
- communication between unconfined domain and any other domain.
- communication between httpd_t and postgresql_t.

In the previous discussion, you were hesitant to add permissions which allows to communicate between widespread domains, so we made a decision to put per-domain interfaces as above.

At first, could you fix its naming scheme?
I think somethind_labeled_tcp_recvfrom(domain) is more obvious to show its meanings.

And, I'm worried about massive enumeration of these interfaces at userdom_basic_networking_template.
Currently, it allows widespread permissions toward any nodes, port and interfaces.
I don't think "daemon_labeled_tcp_recvfrom($1_t)" here makes security degrading. Is it reasonable to allow to communicate between userdomains and daemon attribute?

Thanks,

Hi,

The attached patch allows user domains to communicate with daemon domain, and some other domains (Apache and CGI script) to communicate with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.

This approach enables to cover most of relationship needed. All we have to do is to describe the rest of relationship like ones between CGI script and RDBMS, daemons and name server, anything and samba server, ....

At least, we cannot get labeled networks available unless adding policies to communicate between proper domains.
I think it is necessary to make a decision to describe the policies.

differences
between files
attachment
(refpolicy-labeled_communication.2.patch)

Index: refpolicy/policy/modules/services/apache.if
===================================================================

policy/modules/services/apache.if (working copy) renamed from policy/modules/services/apache.if (revision 2733) +2 -4

@@ -189,10 +189,8 @@
                corenet_udp_sendrecv_all_nodes(httpd_$1_script_t)
                corenet_tcp_sendrecv_all_ports(httpd_$1_script_t)
                corenet_udp_sendrecv_all_ports(httpd_$1_script_t)
-               corenet_tcp_connect_postgresql_port(httpd_$1_script_t)
-               corenet_tcp_connect_mysqld_port(httpd_$1_script_t)
-               corenet_sendrecv_postgresql_client_packets(httpd_
 $1_script_t)
-               corenet_sendrecv_mysqld_client_packets(httpd_
 $1_script_t)
+               postgresql_tcp_connect(httpd_$1_script_t)
+               mysql_tcp_connect(httpd_$1_script_t)
 

                sysnet_read_config(httpd_$1_script_t)
        ')

Index: refpolicy/policy/modules/system/init.if
===================================================================

policy/modules/system/init.if (working copy) renamed from policy/modules/system/init.if (revision 2733) +0 -0

@@ -1273,3 +1273,37 @@
        files_search_pids($1)
        allow $1 initrc_var_run_t:file manage_file_perms;
 ')

policy/modules/system/init.if (working copy) renamed from policy/modules/system/init.if (revision 2733) +7 -0

+interface(`daemon_labeled_tcp_recvfrom',`
+       gen_require(`
+               attribute daemon;
+       ')
+       corenet_tcp_recvfrom_labeled($1,daemon)
+')
+

Quoted 19 lines · KaiGai Kohei

Hi,

The attached patch allows user domains to communicate with daemon domain, and some other domains (Apache and CGI script) to communicate with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.

This approach enables to cover most of relationship needed. All we have to do is to describe the rest of relationship like ones between CGI script and RDBMS, daemons and name server, anything and samba server, ....

At least, we cannot get labeled networks available unless adding policies to communicate between proper domains.
I think it is necessary to make a decision to describe the policies.

Quoted 4 lines

differences
between files
attachment
(refpolicy-labeled_communication.2.patch)

Quoted 17 lines

Index: refpolicy/policy/modules/services/apache.if
===================================================================

policy/modules/services/apache.if (working copy) renamed from policy/modules/services/apache.if (revision 2733) +2 -4

@@ -189,10 +189,8 @@
                corenet_udp_sendrecv_all_nodes(httpd_$1_script_t)
                corenet_tcp_sendrecv_all_ports(httpd_$1_script_t)
                corenet_udp_sendrecv_all_ports(httpd_$1_script_t)
-               corenet_tcp_connect_postgresql_port(httpd_$1_script_t)
-               corenet_tcp_connect_mysqld_port(httpd_$1_script_t)
-               corenet_sendrecv_postgresql_client_packets(httpd_
 $1_script_t)
-               corenet_sendrecv_mysqld_client_packets(httpd_
 $1_script_t)
+               postgresql_tcp_connect(httpd_$1_script_t)
+               mysql_tcp_connect(httpd_$1_script_t)
 

Quoted 2 lines

                sysnet_read_config(httpd_$1_script_t)
        ')

In this case, we want to break out the two databases into individual optionals, e.g.

optional_policy(`
tunable_policy(.... && ....',
mysql_tcp_connect()
')
')

In fact we may want to just duplicate the whole tunable since the other perms don't make much sense if you cant connect to mysql or postgresql.

Quoted 8 lines

Index: refpolicy/policy/modules/system/init.if
===================================================================

policy/modules/system/init.if (working copy) renamed from policy/modules/system/init.if (revision 2733) +0 -0

@@ -1273,3 +1273,37 @@
        files_search_pids($1)
        allow $1 initrc_var_run_t:file manage_file_perms;
 ')

[...]

Quoted 7 lines

policy/modules/system/init.if (working copy) renamed from policy/modules/system/init.if (revision 2733) +7 -0

+interface(`daemon_labeled_tcp_recvfrom',`
+       gen_require(`
+               attribute daemon;
+       ')
+       corenet_tcp_recvfrom_labeled($1,daemon)
+')
+

[...]

policy/modules/system/init.if (working copy)

Quoted 7 lines

policy/modules/system/init.if (working copy) renamed from policy/modules/system/init.if (revision 2733) +6 -0

+interface(`daemon_labeled_udp_recvfrom',`
+       gen_require(`
+               attribute daemon;
+       ')
+       corenet_udp_recvfrom_labeled($1,daemon)
+')

Both interfaces need naming fixes. init_tcp_recvfrom_all_daemons() and init_udp_recvfrom_all_daemons().

Quoted 7 lines · Christopher J. PeBenito

Quoted 6 lines · KaiGai Kohei

Hi,

The attached patch allows user domains to communicate with daemon domain, and some other domains (Apache and CGI script) to communicate with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.

Quoted 8 lines

Quoted 8 lines

This approach enables to cover most of relationship needed. All we have to do is to describe the rest of relationship like ones between CGI script and RDBMS, daemons and name server, anything and samba server, ....

At least, we cannot get labeled networks available unless adding policies to communicate between proper domains.
I think it is necessary to make a decision to describe the policies.

The attached patch is a revised version.
Please review it again.

And I also noticed that ipsec_match_default_spd() should be invoked with server's domain as postgresql_t doing.
(e.g: communication between staff_t and sshd_t)
I think it also should be allowed for whole of daemon attribute. What is your opinion? The version.3 patch also contains this fix.

Quoted 17 lines · KaiGai Kohei

Quoted 7 lines · Christopher J. PeBenito

Quoted 6 lines · KaiGai Kohei

Hi,

The attached patch allows user domains to communicate with daemon domain, and some other domains (Apache and CGI script) to communicate with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.

Quoted 8 lines

Quoted 8 lines

This approach enables to cover most of relationship needed. All we have to do is to describe the rest of relationship like ones between CGI script and RDBMS, daemons and name server, anything and samba server, ....

At least, we cannot get labeled networks available unless adding policies to communicate between proper domains.
I think it is necessary to make a decision to describe the policies.

Quoted 8 lines

The attached patch is a revised version.
Please review it again.

And I also noticed that ipsec_match_default_spd() should be invoked with server's domain as postgresql_t doing.
(e.g: communication between staff_t and sshd_t)
I think it also should be allowed for whole of daemon attribute. What is your opinion? The version.3 patch also contains this fix.

I merged everything except for the default spd part. I don't know if its been suggested before, but I'm considering putting that match rule into corenet_*_recvfrom_unlabeled().

Quoted 27 lines · Chris PeBenito

Quoted 17 lines · KaiGai Kohei

Quoted 7 lines · Christopher J. PeBenito

Quoted 6 lines · KaiGai Kohei

Hi,

The attached patch allows user domains to communicate with daemon domain, and some other domains (Apache and CGI script) to communicate with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.

Quoted 8 lines

Quoted 8 lines

This approach enables to cover most of relationship needed. All we have to do is to describe the rest of relationship like ones between CGI script and RDBMS, daemons and name server, anything and samba server, ....

At least, we cannot get labeled networks available unless adding policies to communicate between proper domains.
I think it is necessary to make a decision to describe the policies.

Quoted 8 lines

The attached patch is a revised version.
Please review it again.

And I also noticed that ipsec_match_default_spd() should be invoked with server's domain as postgresql_t doing.
(e.g: communication between staff_t and sshd_t)
I think it also should be allowed for whole of daemon attribute. What is your opinion? The version.3 patch also contains this fix.

Quoted 3 lines

I merged everything except for the default spd part. I don't know if its been suggested before, but I'm considering putting that match rule into corenet_*_recvfrom_unlabeled().

I'm sorry for neglecting this topic.

Can I understand your suggestion was like the patch I attached with this message? If so, I don't oppose to anything, but we need to put a short description why ipsec_match_default_spd() is deployed on corenet_*_recvfrom_unlabeled() to avoid future confusion.

                   ^^^^^^^^^

Quoted 38 lines · Kohei KaiGai

Quoted 25 lines · Christopher J. PeBenito

Quoted 24 lines · Kohei KaiGai

Quoted 14 lines · Paul Moore

Quoted 13 lines · Kohei KaiGai

Is it acceptable one, if we provide an interface to allow a domain to communicate postgresql_t via labeled networking, separated from existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(postgresql_labeled_connect',

	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)

')

Quoted 7 lines

Quoted 6 lines

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

Quoted 8 lines

Quoted 6 lines

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Chris, is it suitable for refpolicy framework?

The only issue I have with it would just be the interface naming; probably something like mysql_tcp_recvfrom() would be better.

I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means permissions related to labeled networking, or not.

Quoted 6 lines

What do you think the following ideas?
- something_labeled_recvfrom(domain)
or
- something_labeled_tcp_recvfrom(domain)

Thanks,

Oops, I found out this topic has not been progressed for a long time.

An interface of corenet_*_recvfrom_labeled(dom1, dom2) is provided in the latest policy, but nobody uses it except for a few cases like:
- communication between unconfined domain and any other domain.
- communication between httpd_t and postgresql_t.

In the previous discussion, you were hesitant to add permissions which allows to communicate between widespread domains, so we made a decision to put per-domain interfaces as above.

At first, could you fix its naming scheme?
I think somethind_labeled_tcp_recvfrom(domain) is more obvious to show its meanings.

And, I'm worried about massive enumeration of these interfaces at userdom_basic_networking_template.
Currently, it allows widespread permissions toward any nodes, port and interfaces.
I don't think "daemon_labeled_tcp_recvfrom($1_t)" here makes security degrading. Is it reasonable to allow to communicate between userdomains and daemon attribute?

Quoted 17 lines

Quoted 10 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 8 lines

Quoted 6 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and integrate them with the upcaming flow control checks in the future kernel. However, a rule of "allow <domain> self : association {sendto}" will be necessary for the backward compatibility.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

Thanks,

Quoted 58 lines · KaiGai Kohei

Quoted 17 lines

Quoted 10 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 8 lines

Quoted 6 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and integrate them with the upcaming flow control checks in the future kernel. However, a rule of "allow <domain> self : association {sendto}" will be necessary for the backward compatibility.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

Quoted 2 lines

Thanks,

It doesn't seem that the issue of allowing domain polmatch, sendto and recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure what the right answer is but I do know that ipsec is does not work with the current policy.

Quoted 59 lines · Ted X Toth

Quoted 58 lines · KaiGai Kohei

Quoted 17 lines

Quoted 10 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 8 lines

Quoted 6 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and integrate them with the upcaming flow control checks in the future kernel. However, a rule of "allow <domain> self : association {sendto}" will be necessary for the backward compatibility.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

Quoted 6 lines

Quoted 2 lines

Thanks,

It doesn't seem that the issue of allowing domain polmatch, sendto and recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure what the right answer is but I do know that ipsec is does not work with the current policy.

Right, its not completely resolved at the moment. The only labeled networking rules are the ones that KaiGai sent, so I wouldn't expect it to work.

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

I ask because the thread seemed to end. Is there a discussion of a resolution off the list? Is there an issue with adding :
allow domain ipsec_spd_t : association { polmatch sendto recvfrom };

Quoted 79 lines · Ted X Toth

Quoted 59 lines

Quoted 58 lines · KaiGai Kohei

Quoted 17 lines

Quoted 10 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 8 lines

Quoted 6 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and integrate them with the upcaming flow control checks in the future kernel. However, a rule of "allow <domain> self : association {sendto}" will be necessary for the backward compatibility.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

Quoted 6 lines

Quoted 2 lines

Thanks,

It doesn't seem that the issue of allowing domain polmatch, sendto and recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure what the right answer is but I do know that ipsec is does not work with the current policy.

Right, its not completely resolved at the moment. The only labeled networking rules are the ones that KaiGai sent, so I wouldn't expect it to work.

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Quoted 3 lines · Xavier Toth

I ask because the thread seemed to end. Is there a discussion of a resolution off the list? Is there an issue with adding :
allow domain ipsec_spd_t : association { polmatch sendto recvfrom };

I generally have a problem with across-the-board rules like this upstream. Neglecting that, the sendto/recvfrom part doesn't make much sense since sendto should be on self and recvfrom should be on the peer domain.

Quoted 74 lines · Christopher J. PeBenito

Quoted 73 lines · Ted X Toth

Quoted 59 lines

Quoted 58 lines · KaiGai Kohei

Quoted 17 lines

Quoted 10 lines

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };" at ipsec_match_default_spd interface of ipsec.if?

I think it should be packed with polmatch permission to the default SPD context, because any domain which want to communicate others using SPD with default context always have to have 'sendto' permission to itself.

Perhaps. Though I thought that dropping the sendto check was being considered, since it really doesn't gain anything.

Quoted 3 lines

2. Is it considerable to add "ipsec_match_default_spd($1_t)" in the userdom_basic_networking_template of userdomain.if?

Quoted 8 lines

Quoted 6 lines

This interface allows a given userdomain widespread basic networking permissions. But it is not enough yet, if the networking tunnel is configured with labeled ipsec.
I think it can be contained in the basic networking permissions to use ipsec SPD with default context.

Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and integrate them with the upcaming flow control checks in the future kernel. However, a rule of "allow <domain> self : association {sendto}" will be necessary for the backward compatibility.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

I'll consider a patch that adds it to a postresql interface. Perhaps postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via labeled ipsec with default SPD, and attaching it both a server domain and a client domain?

e.g)
attribute labeled_communicatable_domain; # I want to get more shorl naming.
allow labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

typeattribute postgresql_t, labeled_communicate_domain; typeattribute user_t, labeled_communicate_domain;

Quoted 6 lines

Quoted 2 lines

Thanks,

It doesn't seem that the issue of allowing domain polmatch, sendto and recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure what the right answer is but I do know that ipsec is does not work with the current policy.

Right, its not completely resolved at the moment. The only labeled networking rules are the ones that KaiGai sent, so I wouldn't expect it to work.

Quoted 6 lines

Quoted 6 lines

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

--

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150