Mailing List Archive

On Thu, Dec 01, 2016 at 10:24:21AM +0000, Robert Sharp wrote:
> Hi,
>
>
> I've looked at the Gentoo SELinux web pages etc, the SELinux Handbook
> and through the Reference Policy and I cannot find the answer to a
> simple question.
>
> I am writing a small policy for my backup system and I want to be able
> to a) access a MongoDB running on remote servers, and b) use rsync. I
> can see two AVCs relating to my port use and I know how I can fix the
> problem from the command line, but surely I should be able to address
> this in the policy? I think there is an rsync interface I need to call
> (rsync_entry_type(mytype_t)) and I assume this will run rsync in the
> right domain?
>
> Mongo has a policy but the only interface is admin. All I need to do
> locally is connect to the port. Can I use "portcon" in a policy to do
> this or do I need to do something else?
>
> Thanks,
>
> Robert Sharp

What port number is it using? does that port already have a label? if it
does then you use the corenet stuff, eg:

corenet_tcp_connect_mysqld_port(foo_t) would allow foo_t to connect to
these ports:

# semanage port -l | grep mysql
mysqld_port_t tcp 1186, 3306, 63132-63164

if there is no good label on the port currently, you can define your own
with semanage port. or it can be added to the base policy, because of
the way pp files work, you cannot do portcon in a module. If there is a
port that is missing a label, we can add it to the base in both refpol
and gentoos policy.

Look at policy/modules/kernel/corenetwork.te.in in the policy for
adding a new one.

As for rsync, if you want your script to be able to run it without
changing domain, you probably want rsync_exec(), if you want to transition
to rsync_t, then rsync_domtrans()

-- Jason

On 01/12/16 15:31, Jason Zaman wrote:
> On Thu, Dec 01, 2016 at 10:24:21AM +0000, Robert Sharp wrote:
>> Hi,
>>
>>
>> I've looked at the Gentoo SELinux web pages etc, the SELinux Handbook
>> and through the Reference Policy and I cannot find the answer to a
>> simple question.
>>
>> I am writing a small policy for my backup system and I want to be able
>> to a) access a MongoDB running on remote servers, and b) use rsync. I
>> can see two AVCs relating to my port use and I know how I can fix the
>> problem from the command line, but surely I should be able to address
>> this in the policy? I think there is an rsync interface I need to call
>> (rsync_entry_type(mytype_t)) and I assume this will run rsync in the
>> right domain?
>>
>> Mongo has a policy but the only interface is admin. All I need to do
>> locally is connect to the port. Can I use "portcon" in a policy to do
>> this or do I need to do something else?
>>
>> Thanks,
>>
>> Robert Sharp
> What port number is it using? does that port already have a label? if it
> does then you use the corenet stuff, eg:
>
> corenet_tcp_connect_mysqld_port(foo_t) would allow foo_t to connect to
> these ports:
>
> # semanage port -l | grep mysql
> mysqld_port_t tcp 1186, 3306, 63132-63164
>
> if there is no good label on the port currently, you can define your own
> with semanage port. or it can be added to the base policy, because of
> the way pp files work, you cannot do portcon in a module. If there is a
> port that is missing a label, we can add it to the base in both refpol
> and gentoos policy.
>
> Look at policy/modules/kernel/corenetwork.te.in in the policy for
> adding a new one.
>
> As for rsync, if you want your script to be able to run it without
> changing domain, you probably want rsync_exec(), if you want to transition
> to rsync_t, then rsync_domtrans()
>
> -- Jason
>
Mongo uses tcp on port 27017 and there is nothing defined for this in
the core policy. There is a mongodb policy in contrib but it uses
corenet_all_recvfrom_unlabeled, corenet_tcp_sendrecv_generic_if and the
likes.

From what I can make out, semanage port will only allow me to assign a
port to an existing label? Looks like I can only define a port label in
the reference policy? What is the best way forward? If I was to add
something to corenetwork.te it would look like this, I guess:

type mongodb_port_t, port_type, defined_port_type;
type mongodb_client_packet_t, packet_type, client_packet_type;
type mongodb_server_packet_t, packet_type, server_packet_type;
typeattribute mongodb_port_t unreserved_port_type;
portcon tcp 27017 gen_context(system_u:object_r:mongodb_port_t,s0)

Would that then create a "corenet_tcp_connect_mongodb_port" interface?

Incidentally, if I have a little family of apps that use use a number of
unreserved ports. Seems a little monolithic if the only way I can
integrate them is to have them included in the base policy? Luckily they
are not on the machine I am trying to get to strict atm, but they are on
the next one.

Thanks for your help, as always!

Robert

On Fri, Dec 02, 2016 at 12:05:50PM +0000, Robert Sharp wrote:
> Mongo uses tcp on port 27017 and there is nothing defined for this in
> the core policy. There is a mongodb policy in contrib but it uses
> corenet_all_recvfrom_unlabeled, corenet_tcp_sendrecv_generic_if and the
> likes.
>
> From what I can make out, semanage port will only allow me to assign a
> port to an existing label? Looks like I can only define a port label in
> the reference policy? What is the best way forward? If I was to add
> something to corenetwork.te it would look like this, I guess:
>
> type mongodb_port_t, port_type, defined_port_type;
> type mongodb_client_packet_t, packet_type, client_packet_type;
> type mongodb_server_packet_t, packet_type, server_packet_type;
> typeattribute mongodb_port_t unreserved_port_type;
> portcon tcp 27017 gen_context(system_u:object_r:mongodb_port_t,s0)
>
> Would that then create a "corenet_tcp_connect_mongodb_port" interface?
>
> Incidentally, if I have a little family of apps that use use a number
> of unreserved ports. Seems a little monolithic if the only way I can
> integrate them is to have them included in the base policy? Luckily
> they are not on the machine I am trying to get to strict atm, but they
> are on the next one.

I know you can't define a port mapping in the "legacy" (for lack of a better
name, call it .pp or so if you want ;) approach, but can't we define a port
type in a module, and then use the 'semanage port' command to map it to the
right port?

Another approach that works is to create your port definition with CIL. See
the following two posts (the CIL code is in the first, loading in the second
as the first post didn't know yet they were directly loadable):

http://blog.siphos.be/2015/06/where-does-cil-play-in-the-selinux-system/
http://blog.siphos.be/2015/07/loading-cil-modules-directly/

Wkr,
Sven Vermeulen

On 03/12/16 10:16, Sven Vermeulen wrote:
> On Fri, Dec 02, 2016 at 12:05:50PM +0000, Robert Sharp wrote:
>> Mongo uses tcp on port 27017 and there is nothing defined for this in
>> the core policy. There is a mongodb policy in contrib but it uses
>> corenet_all_recvfrom_unlabeled, corenet_tcp_sendrecv_generic_if and the
>> likes.
> I know you can't define a port mapping in the "legacy" (for lack of a better
> name, call it .pp or so if you want ;) approach, but can't we define a port
> type in a module, and then use the 'semanage port' command to map it to the
> right port?
>
> Another approach that works is to create your port definition with CIL. See
> the following two posts (the CIL code is in the first, loading in the second
> as the first post didn't know yet they were directly loadable):
>
> http://blog.siphos.be/2015/06/where-does-cil-play-in-the-selinux-system/
> http://blog.siphos.be/2015/07/loading-cil-modules-directly/
>
> Wkr,
> Sven Vermeulen
>
Thanks for this. I wrote a little CIL snippet based on your example for
27017 and semodule'd it in. I could then see the port with semanage port
-l and I could use it in the .te file as well. I made a mistake first
time round by naming the .cil file the same as the others, which create
mayhem when I tried importing the module. I removed the .cil bit,
renamed it mongodb.cil and tried again. This time it worked. I guess I
ought to look at the mongodb in contrib to see if there should be a
client side to the policy, and perhaps rename my CIL to something like
mongodb_port.cil.

Is there a plan to move everything to CIL? It is just that you referred
to the .pp approach as "legacy". I just wonder because CIL looks fairly
unfriendly and may even be an intermediate language. Also, are there any
plans to make the whole thing more modular? Looking at corenetwork.if,
for example, is a bit of a surprise.

Best regards,

Robert

On Sun, Dec 04, 2016 at 04:53:49PM +0000, Robert Sharp wrote:
> Thanks for this. I wrote a little CIL snippet based on your example for
> 27017 and semodule'd it in. I could then see the port with semanage port
> -l and I could use it in the .te file as well. I made a mistake first
> time round by naming the .cil file the same as the others, which create
> mayhem when I tried importing the module. I removed the .cil bit,
> renamed it mongodb.cil and tried again. This time it worked. I guess I
> ought to look at the mongodb in contrib to see if there should be a
> client side to the policy, and perhaps rename my CIL to something like
> mongodb_port.cil.
>
> Is there a plan to move everything to CIL? It is just that you referred
> to the .pp approach as "legacy". I just wonder because CIL looks fairly
> unfriendly and may even be an intermediate language. Also, are there any
> plans to make the whole thing more modular? Looking at corenetwork.if,
> for example, is a bit of a surprise.

I am not aware of an active project (in Gentoo or outside) to build up or
migrate the current policy towards CIL. There have been a couple of tests on
this (there once was a cilrefpolicy project, and Dominick Grift maintains a
CIL-only policy but I don't know if that one is usable in a larger context,
and I think he shares it more from a "sharing knowledge" perspective rather
than "please contribute to make it work for distributions").

The reason I quoted "legacy" is because the current policy is actually using
CIL when you run with the user space project version 2.4 or later. The
binary .pp file is translated into CIL in the background. The SELinux
project calls this HLL (High Level Language) although I wouldn't call the
binary .pp format as "high level". But it is nice that this translation is
already put in place, because it shows that CIL by itself is
production-ready.

I have thought about starting a CIL-only policy with the intention of making
it reusable for multiple users, but given my current time constraints I'm
confident that that project would fail to start.

One day though... ;-)

Wkr,
Sven Vermeulen