<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dan, Mr. Dash Four,<br>
<br>
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:<br>
<ol>
<li>restrict sockets a domain is allowed to listen on to only
accept packets from a certain IP address and/or network
interface</li>
<li>restrict TCP connections from a domain under my control to
other potentially unrestricted domains.</li>
<li>restrict TCP connections from a domain under my control to
processes on other machines that do not have SELinux installed.</li>
</ol>
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.<br>
<br>
Here are parts of the policies I currently have working. Let me know
if full policies are needed to take this further.<br>
<br>
===<br>
policy_module(CZla,1.0.0)<br>
...<br>
type CZla_port_t;<br>
corenet_port(CZla_port_t)<br>
<br>
require {<br>
type CZla_t;<br>
type CZla_port_t;<br>
...<br>
}<br>
allow CZla_t CZla_port_t:tcp_socket { name_bind };<br>
...<br>
===<br>
<br>
I was also able to specify restrictions on what connections other
processes that I have custom policies for might create via policies
like these:<br>
<br>
===<br>
policy_module(CZtp,1.0.0)<br>
...<br>
require {<br>
type CZtp_t;<br>
type CZla_port_t;<br>
...<br>
}<br>
allow CZtp_t CZla_port_t:tcp_socket name_connect;<br>
===<br>
<br>
How to I take these policies forward to get to the more fine-grained
restrictions I list above?<br>
<br>
Thanks<br>
Michael<br>
<br>
<br>
<br>
On 1/11/2012 11:34 PM, Mr Dash Four wrote:
<blockquote cite="mid:4F0E0E80.2060706@googlemail.com" type="cite">
<br>
<blockquote type="cite">Sounds good, could you get this
upstreamed.
<br>
</blockquote>
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.
<br>
<br>
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).
<br>
<br>
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!
<br>
<br>
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.
<br>
<br>
<blockquote type="cite"> My only problem would be
<br>
with unconfined_domains, since I am not crazy about confining
<br>
something we say is unconfined. Secondly you might want to
allow
<br>
processes to connect to port 2222 on a different machine but
not at
<br>
localhost.
<br>
</blockquote>
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.
<br>
<br>
<blockquote type="cite">Yes I have changed some of this handling
in Fedora but not upstreamed
<br>
</blockquote>
Yeah, it needed to - it was a nasty shock when I first looked at
it.
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Michael Atighetchi
Senior Scientist
Raytheon BBN Technologies
617-873-1679
<a class="moz-txt-link-abbreviated" href="mailto:matighet@bbn.com">matighet@bbn.com</a>
</pre>
</body>
</html>