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@xxxxxxx
|
