Limiting the power of can_network, improving the security of strict policy.

Limiting the power of can_network, improving the security of strict policy.

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

We have been talking about ways of improving the security of strict 
policy.  So I have been working
to eliminate tunables and replace them with booleans.   So an 
administrator can easily turn them off.
(allow_ypbind and use_nfs_home_dirs defaulting to off as an example).

Also I have been working to eliminate the ncsd_ tunables by adding 
ncsd_client_domain to all daemons that need it.

Finally we are looking into limiting the power of can_network.  
Currently any daemon that has can_network can receive
and establish TCP/UDP connections.  The only thing not provided is 
name_bind.  I want to break this out to eliminate the
ability for daemons also to connect.  So an incoming only daemon, can 
not establish a connection back out.  To do this
I have modified create_socket_perms and eliminated the connect call.  I 
have added a connect_socket_perms which includes
the create_socket_perms.  This has caused many changes to be made in 
policy, and I am not sure if it was a good idea?

Also I modified can_network to take a second parameter of the type of 
the connection (udp or tcp).  This allows you to turn off tcp, connections
on a UDP application.  (I am not sure you can do this for a tcp only app 
if they are going to use name service.)

Is this a good idea or am I wasting my time?

Dan

[-- Attachment #2: network_macros.te --]
[-- Type: text/plain, Size: 2032 bytes --]

#################################
#
# can_network(domain)
#
# Permissions for accessing the network.
# See types/network.te for the network types.
# See net_contexts for security contexts for network entities.
#
define(`base_can_network',`
#
# Allow the domain to create and use $2 sockets.
# Other kinds of sockets must be separately authorized for use.
allow $1 self:$2_socket create_socket_perms;

#
# Allow the domain to send or receive using any network interface.
# netif_type is a type attribute for all network interface types.
#
allow $1 netif_type:netif { $2_send rawip_send };
allow $1 netif_type:netif { $2_recv rawip_recv };

#
# Allow the domain to send to or receive from any node.
# node_type is a type attribute for all node types.
#
allow $1 node_type:node { $2_send rawip_send };
allow $1 node_type:node { $2_recv rawip_recv };

#
# Allow the domain to send to or receive from any port.
# port_type is a type attribute for all port types.
#
allow $1 $3:{ $2_socket } { send_msg recv_msg };

# XXX Allow binding to any node type.  Remove once
# individual rules have been added to all domains that 
# bind sockets. 
allow $1 node_type: { $2_socket } node_bind;
')dnl end can_network definition

#################################
#
# can_network(domain)
#
# Permissions for accessing the network.
# See types/network.te for the network types.
# See net_contexts for security contexts for network entities.
#
define(`can_network',`

ifelse($2, `', `
base_can_network($1, udp, port_type)
base_can_network($1, tcp, port_type)
allow $1 self:tcp_socket { listen accept };
', `
ifelse($3, `', `
base_can_network($1, $2, $3)
', `
base_can_network($1, $2, port_type)
') dnl ifelse $3
ifelse($2, `tcp', `
allow $1 self:tcp_socket { listen accept };
')
')

#
# Allow the domain to send NFS client requests via the socket
# created by mount.
#
allow $1 mount_t:udp_socket rw_socket_perms;

#
# Allow access to network files including /etc/resolv.conf
#
allow $1 net_conf_t:file r_file_perms;
')dnl end can_network definition

Re: Limiting the power of can_network, improving the security of strict policy.

[steven harp]

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

On Wednesday 27 October 2004 10:04 am, Daniel J Walsh wrote:
> We have been talking about ways of improving the security of strict 
> policy.  So I have been working
> ...
> Finally we are looking into limiting the power of can_network.  
> Currently any daemon that has can_network can receive
> and establish TCP/UDP connections.  The only thing not provided is 
> name_bind.  I want to break this out to eliminate the
> ability for daemons also to connect.  So an incoming only daemon, can 
> not establish a connection back out.  To do this
> I have modified create_socket_perms and eliminated the connect call.  I 
> have added a connect_socket_perms which includes
> the create_socket_perms.  This has caused many changes to be made in 
> policy, and I am not sure if it was a good idea?
> 
> Also I modified can_network to take a second parameter of the type of 
> the connection (udp or tcp).  This allows you to turn off tcp, connections
> on a UDP application.  (I am not sure you can do this for a tcp only app 
> if they are going to use name service.)
> 
> Is this a good idea or am I wasting my time?

I like the direction of suggested mods to can_network.  I've mostly abandoned 
use of this macro for a suite of distributed applications I'm working
on since it does usually offer more than any one of the apps really needs.
Providing more modular connection-oriented constructions would be useful.

Steven Harp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBf7whPcFX9H2zuSkRAkH5AJ4k9QD/ORwZMIwVRMHdOP3BRb322gCeJzH1
y7M2WZa0BwL14wz8/gwbPn8=
=p0WO
-----END PGP SIGNATURE-----



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Limiting the power of can_network, improving the security of strict policy.

[Russell Coker]

On Wed, 2004-10-27 at 11:04 -0400, Daniel J Walsh wrote:
> Finally we are looking into limiting the power of can_network.  
> Currently any daemon that has can_network can receive
> and establish TCP/UDP connections.  The only thing not provided is 
> name_bind.  I want to break this out to eliminate the
> ability for daemons also to connect.  So an incoming only daemon, can 
> not establish a connection back out.  To do this
> I have modified create_socket_perms and eliminated the connect call.  I 
> have added a connect_socket_perms which includes
> the create_socket_perms.  This has caused many changes to be made in 
> policy, and I am not sure if it was a good idea?

I think it might be better to leave create_socket_perms as it is and
have another macro connected_socket_perms which doesn't have create
access.

> Also I modified can_network to take a second parameter of the type of 
> the connection (udp or tcp).  This allows you to turn off tcp, connections
> on a UDP application.  (I am not sure you can do this for a tcp only app 
> if they are going to use name service.)

What if we have two new macros can_tcp_network() and can_udp_network()
which can_network() invokes.

> Is this a good idea or am I wasting my time?

It's a great idea!  But I think some minor changes to the way that
backward compatability works would be good.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Limiting the power of can_network, improving the security of strict policy.

[Jayendren Anand Maduray]

Hi ppl!

Just wondering about SELinux,
Are there n e plans to incorporate biometrics as well as VOS (Virtual
Operating System) architecture to allow a more secure method of
authentication?
God bless. 

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
Behalf Of steven harp
Sent: 27 October 2004 05:18 PM
To: SELinux
Subject: Re: Limiting the power of can_network, improving the security of
strict policy.

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

On Wednesday 27 October 2004 10:04 am, Daniel J Walsh wrote:
> We have been talking about ways of improving the security of strict 
> policy.  So I have been working
> ...
> Finally we are looking into limiting the power of can_network.  
> Currently any daemon that has can_network can receive
> and establish TCP/UDP connections.  The only thing not provided is 
> name_bind.  I want to break this out to eliminate the
> ability for daemons also to connect.  So an incoming only daemon, can 
> not establish a connection back out.  To do this
> I have modified create_socket_perms and eliminated the connect call.  I 
> have added a connect_socket_perms which includes
> the create_socket_perms.  This has caused many changes to be made in 
> policy, and I am not sure if it was a good idea?
> 
> Also I modified can_network to take a second parameter of the type of 
> the connection (udp or tcp).  This allows you to turn off tcp, connections
> on a UDP application.  (I am not sure you can do this for a tcp only app 
> if they are going to use name service.)
> 
> Is this a good idea or am I wasting my time?

I like the direction of suggested mods to can_network.  I've mostly
abandoned 
use of this macro for a suite of distributed applications I'm working
on since it does usually offer more than any one of the apps really needs.
Providing more modular connection-oriented constructions would be useful.

Steven Harp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBf7whPcFX9H2zuSkRAkH5AJ4k9QD/ORwZMIwVRMHdOP3BRb322gCeJzH1
y7M2WZa0BwL14wz8/gwbPn8=
=p0WO
-----END PGP SIGNATURE-----



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Limiting the power of can_network, improving the security of strict policy.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Wed, 27 Oct 2004 19:27:48 +0200, Jayendren Anand Maduray said:

> Are there n e plans to incorporate biometrics as well as VOS (Virtual
> Operating System) architecture to allow a more secure method of
> authentication?

SELinux is about *authorization*, not authentication.  Your best bet for
securing authentication is to look at customize PAM modules - SELinux
basically assumes that "If PAM allowed this user to login this role, they
must be authenticated, so we'll provide authorization appropriate for
the user's role".

Note that biometrics do *not* automagically make it more secure - in
particular, they don't do very much at all for securing network access.
Improperly used, they make things *worse* (how do you revoke credentials
based on an iris scanner, for instance? ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Limiting the power of can_network, improving the security of strict policy.

[Russell Coker]

On Thu, 28 Oct 2004 06:39, Valdis.Kletnieks@vt.edu wrote:
> SELinux is about *authorization*, not authentication.  Your best bet for
> securing authentication is to look at customize PAM modules - SELinux
> basically assumes that "If PAM allowed this user to login this role, they
> must be authenticated, so we'll provide authorization appropriate for
> the user's role".

There is a SE Linux related issue in this.  In the future we will be 
supporting other methods of authentication.  There are useful methods of 
authentication such as smart-cards which may have similar interfaces to the 
OS as useless things such as biometrics.

We need to make sure that only certain applications can communicate with the 
authentication hardware, and the hardware in question may have multiple 
capabilities (think of a smart-card that authenticates the user and also has 
a GPG implementation).  So we will probably need a user-space object manager 
to control access to the security hardware.  Finally we need a trusted path 
so that a GPG card will only sign things when instructed by the user (not a 
trojan).

> Note that biometrics do *not* automagically make it more secure - in
> particular, they don't do very much at all for securing network access.
> Improperly used, they make things *worse* (how do you revoke credentials
> based on an iris scanner, for instance? ;)

Remove the eye.  ;)

One big disadvantage of biometric systems is the risk of theft.  Having keys 
or cards stolen is bad, having an eye or a finger stolen is really bad.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.