FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 01-11-2012, 11:54 AM
Michael Atighetchi
 
Default adding port restrictions to policy generated by sepolgen

Hi,

I have a question about how to restrict network access via SELinux.I
generated a policy via sepolgen on Fedora 14, and there are some network
specific rules and macros in it, for example:


corenet_tcp_bind_generic_node(CZtp_t)
corenet_tcp_connect_postgresql_port(CZtp_t)
corenet_tcp_connect_vnc_port(CZtp_t)
corenet_udp_bind_generic_node(CZtp_t)

allow CZtp_t self:tcp_socket { setopt read bind create accept write
getattr connect shutdown getopt listen };
allow CZtp_t self:udp_socket { setopt read bind create ioctl write
getattr connect getopt };


Here is what I would like to change
1) Restrict privs so that the process can only bind to a specific custom
port, e.g., 2222 (controlled by my app)
2) Restrict privs so that the only processes on the local machine
allowed to connect to this port is in the same domain as the process who
created the listening socket (same policy as above)


Is this doable?

--
Michael Atighetchi
Senior Scientist
Raytheon BBN Technologies
617-873-1679
matighet@bbn.com

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-11-2012, 03:16 PM
Daniel J Walsh
 
Default adding port restrictions to policy generated by sepolgen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/11/2012 07:54 AM, Michael Atighetchi wrote:
> Hi,
>
> I have a question about how to restrict network access via
> SELinux.I generated a policy via sepolgen on Fedora 14, and there
> are some network specific rules and macros in it, for example:
>
> corenet_tcp_bind_generic_node(CZtp_t)
> corenet_tcp_connect_postgresql_port(CZtp_t)
> corenet_tcp_connect_vnc_port(CZtp_t)
> corenet_udp_bind_generic_node(CZtp_t)
>
> allow CZtp_t self:tcp_socket { setopt read bind create accept
> write getattr connect shutdown getopt listen }; allow CZtp_t
> self:udp_socket { setopt read bind create ioctl write getattr
> connect getopt };
>
> Here is what I would like to change 1) Restrict privs so that the
> process can only bind to a specific custom port, e.g., 2222
> (controlled by my app) 2) Restrict privs so that the only processes
> on the local machine allowed to connect to this port is in the same
> domain as the process who created the listening socket (same policy
> as above)
>
> Is this doable?
>
Creating a daemon that can only bind to port 2222 is very doable.

sepolgen only will setup a framework to write policy, it can not
handle all situations. (selinux-polgengui, can handle this one BTW).

http://danwalsh.livejournal.com/10607.html

Explains how to do this.

Preventing all other domains from connecting to port 2222, is much
more difficult. You might have to turn on seclabel to achieve this.
Since there are many domains that are allowed to connect to all ports.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8NtfMACgkQrlYvE4MpobMAxwCfSILoTsa6lv 9tP8c535BjC7oq
vFMAoJ66IvlQ+4aMR0QomQ3FWpJpMdmM
=1aMM
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-11-2012, 04:22 PM
Mr Dash Four
 
Default adding port restrictions to policy generated by sepolgen

Preventing all other domains from connecting to port 2222, is much
more difficult.
No, it's not! I have a very similar setup to what Michael describes in
his post. This was prompted by a common theme running through all Fedora
net policies for granting permissions to defined ports regardless of
whether they are actually used/needed or not, including access to all
ports - something which I was deeply unhappy about, though I accept that
selinux-policy(-targeted) is not defined just for the set of machines I
deploy, but for millions of other users, so that's fair enough, I suppose.


To avoid granting such permissions willy-nilly I redefined two aspects
of the "default" Fedora policies: I've included a definition of a new
type called 'pk_type' (instead of the "standard" packet_type used) and
'prt_type' (instead of the "standard" port_type). There are, generally
speaking, 4 files responsible for all net policy definitions and further
macro generation used throughout: corenetwork.te{.in,.m4} as well as
corenetwork.if{.in,.m4}, so all I had to do is extend these definitions
for the custom-defined prt_type and pk_type for the (custom)
ports/packets used on my system (that would be 2222 in Michael's case)
and that would be that, assuming he also alters the policy (or policies)
of the domains who need access to this particular port - that is crucial.



You might have to turn on seclabel to achieve this.
Since there are many domains that are allowed to connect to all ports.

If seclabel is used, then a simple re-definition of pk_type from the
"standard" packet_type would be enough. A word of warning though:
"packet_type" is a parent of "server_packet_type" and
"client_packet_type", so these types would also need to be redefined in
order for packet_type restrictions to be useful. Also, simply redefining
server_packet_type or client_packet_type won't be enough because I found
that there are domains with "grant" permissions to the base "packet_type".


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-11-2012, 05:45 PM
Daniel J Walsh
 
Default adding port restrictions to policy generated by sepolgen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/11/2012 12:22 PM, Mr Dash Four wrote:
>
>> Preventing all other domains from connecting to port 2222, is
>> much more difficult.
> No, it's not! I have a very similar setup to what Michael describes
> in his post. This was prompted by a common theme running through
> all Fedora net policies for granting permissions to defined ports
> regardless of whether they are actually used/needed or not,
> including access to all ports - something which I was deeply
> unhappy about, though I accept that selinux-policy(-targeted) is
> not defined just for the set of machines I deploy, but for millions
> of other users, so that's fair enough, I
suppose.
>
> To avoid granting such permissions willy-nilly I redefined two
> aspects of the "default" Fedora policies: I've included a
> definition of a new type called 'pk_type' (instead of the
> "standard" packet_type used) and 'prt_type' (instead of the
> "standard" port_type). There are, generally speaking, 4 files
> responsible for all net policy definitions and further macro
> generation used throughout: corenetwork.te{.in,.m4} as well as
> corenetwork.if{.in,.m4}, so all I had to do is extend these
> definitions for the custom-defined prt_type and pk_type for the
> (custom) ports/packets used on my system (that would be 2222 in
> Michael's case) and that would be that, assuming he also alters the
> policy (or policies) of the domains who need access to this
> particular port - that is
crucial.
>
Sounds good, could you get this upstreamed. My only problem would be
with unconfined_domains, since I am not crazy about confining
something we say is unconfined. Secondly you might want to allow
processes to connect to port 2222 on a different machine but not at
localhost.

>> You might have to turn on seclabel to achieve this. Since there
>> are many domains that are allowed to connect to all ports.
>>
> If seclabel is used, then a simple re-definition of pk_type from
> the "standard" packet_type would be enough. A word of warning
> though: "packet_type" is a parent of "server_packet_type" and
> "client_packet_type", so these types would also need to be
> redefined in order for packet_type restrictions to be useful. Also,
> simply redefining server_packet_type or client_packet_type won't be
> enough because I found that there are domains with "grant"
> permissions to the base
"packet_type".
>

Yes I have changed some of this handling in Fedora but not upstreamed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8N2OMACgkQrlYvE4MpobOUIgCgix7jDjz2Pa xK/CR1wFPNRu2i
xeMAoOvBYQOyk0H5AVMGLJBaO6wNIQ61
=mQiK
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-11-2012, 09:34 PM
Mr Dash Four
 
Default adding port restrictions to policy generated by sepolgen

Sounds good, could you get this upstreamed.
I could (it is one gigantic patch, dynamically generated - using bash
script - depending on the policy source version as I use 3 different
ones), but it is system specific and I very much doubt that it would
work on machines which have "generic" configurations. For starters, I
have redefined 98% of the "standard" ports used in corenetwork.te.in,
redefined the two packet and port types as I stated in my previous post,
and then patched *only* the policies (.te, .if files in particular) I
use for the machine(s) on which this policy is deployed.


By doing this, I avoid the general port and packet definitions (and
allowing access to these ports "by default") which exist in all other
modules and use/define only those I *specifically* use on the target
machines. It is a very simple principle, driven by the lack of
flexibility in the current SELinux policies with regards to network
support (nodes, interfaces, ports and packet types).


One customary look in a .te file will tell you that access to *any*
(general) node is most likely granted, access to *any* general network
interface is also most-likely granted and the chances are, that there
would be one statement or another in the net policy section which grants
access to a port, or variety of ports, to which the given policy file
may not be needed, hence why I redefine these for my specific
configuration - saves a lot of headaches. Currently, there is no other
way for me to do this!


It would have been better if the SELinux policies were more flexible and
in addition to grant/deny access to particular ports *I use*, I could
also remove all the unnecessary modules from the policy (better
performance, better memory footprint) without nasty side effects, but it
is not to be and I have to revert to such gimmicks like the above in
order to do what I want in the end.



My only problem would be
with unconfined_domains, since I am not crazy about confining
something we say is unconfined. Secondly you might want to allow
processes to connect to port 2222 on a different machine but not at
localhost.

That is where the "local" (or any other) nd_type comes in (the
"standard" node_type for you and me - oh yes, I redefined that as well)
- I alter only the policies to which a given set of processes/domains
need access and leave out the rest as they have no knowledge/access
granted "by default" to the new node, port or packet definitions, so
there is no danger of me granting something I shouldn't.



Yes I have changed some of this handling in Fedora but not upstreamed


Yeah, it needed to - it was a nasty shock when I first looked at it.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-16-2012, 10:01 AM
Michael Atighetchi
 
Default adding port restrictions to policy generated by sepolgen

Dan, Mr. Dash Four,



thanks - I was able to follow the initial directions Dan provided
and specify some restrictions on TCP ports a module is allowed to
listen on/ connect to. However, I do would like to specify
additional restrictions of the kind:


restrict sockets a domain is allowed to listen on to only
accept packets from a certain IP address and/or network
interface
restrict TCP connections from a domain under my control to
other potentially unrestricted domains.
restrict TCP connections from a domain under my control to
processes on other machines that do not have SELinux installed.

Reading through the writeup Mr. Dash Four provides, I believe to
understand the general gist, but I'm not sure what changes to make
to my policies (and maybe the default targeted policy on Fedora 14)
to make that happen.



Here are parts of the policies I currently have working. Let me know
if full policies are needed to take this further.



===

policy_module(CZla,1.0.0)

...

type CZla_port_t;

corenet_port(CZla_port_t)



require {

******* type CZla_t;

******* type CZla_port_t;

******* ...

}

allow CZla_t CZla_port_t:tcp_socket { name_bind };

...

===



I was also able to specify restrictions on what connections other
processes that I have custom policies for might create via policies
like these:



===

policy_module(CZtp,1.0.0)

...

require {

******* type CZtp_t;

******* type CZla_port_t;

******* ...

}

allow CZtp_t CZla_port_t:tcp_socket name_connect;

===



How to I take these policies forward to get to the more fine-grained
restrictions I list above?



Thanks

Michael







On 1/11/2012 11:34 PM, Mr Dash Four wrote:



Sounds good, could you get this
upstreamed.



I could (it is one gigantic patch, dynamically generated - using
bash script - depending on the policy source version as I use 3
different ones), but it is system specific and I very much doubt
that it would work on machines which have "generic"
configurations. For starters, I have redefined 98% of the
"standard" ports used in corenetwork.te.in, redefined the two
packet and port types as I stated in my previous post, and then
patched *only* the policies (.te, .if files in particular) I use
for the machine(s) on which this policy is deployed.




By doing this, I avoid the general port and packet definitions
(and allowing access to these ports "by default") which exist in
all other modules and use/define only those I *specifically* use
on the target machines. It is a very simple principle, driven by
the lack of flexibility in the current SELinux policies with
regards to network support (nodes, interfaces, ports and packet
types).




One customary look in a .te file will tell you that access to
*any* (general) node is most likely granted, access to *any*
general network interface is also most-likely granted and the
chances are, that there would be one statement or another in the
net policy section which grants access to a port, or variety of
ports, to which the given policy file may not be needed, hence why
I redefine these for my specific configuration - saves a lot of
headaches. Currently, there is no other way for me to do this!




It would have been better if the SELinux policies were more
flexible and in addition to grant/deny access to particular ports
*I use*, I could also remove all the unnecessary modules from the
policy (better performance, better memory footprint) without nasty
side effects, but it is not to be and I have to revert to such
gimmicks like the above in order to do what I want in the end.




* My only problem would be


with unconfined_domains, since I am not crazy about confining


something we say is unconfined.* Secondly you might want to
allow


processes to connect to port 2222 on* a different machine but
not at


localhost.


*
That is where the "local" (or any other) nd_type comes in (the
"standard" node_type for you and me - oh yes, I redefined that as
well) - I alter only the policies to which a given set of
processes/domains need access and leave out the rest as they have
no knowledge/access granted "by default" to the new node, port or
packet definitions, so there is no danger of me granting something
I shouldn't.




Yes I have changed some of this handling
in Fedora but not upstreamed


*
Yeah, it needed to - it was a nasty shock when I first looked at
it.







--
Michael Atighetchi
Senior Scientist
Raytheon BBN Technologies
617-873-1679
matighet@bbn.com



--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 10:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org