All of lore.kernel.org
 help / color / mirror / Atom feed
From: steven harp <steven.harp@adventiumlabs.org>
To: SELinux <SELinux@tycho.nsa.gov>
Subject: Re: Limiting the power of can_network, improving the security of strict policy.
Date: Wed, 27 Oct 2004 10:17:38 -0500	[thread overview]
Message-ID: <200410271017.59218.steven.harp@adventiumlabs.org> (raw)
In-Reply-To: <417FB917.8030109@redhat.com>

-----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.

  reply	other threads:[~2004-10-27 15:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-27 15:04 Limiting the power of can_network, improving the security of strict policy Daniel J Walsh
2004-10-27 15:17 ` steven harp [this message]
2004-10-27 17:27   ` Jayendren Anand Maduray
2004-10-27 20:39     ` Valdis.Kletnieks
2004-10-28 11:07       ` Russell Coker
2004-10-27 15:18 ` Russell Coker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200410271017.59218.steven.harp@adventiumlabs.org \
    --to=steven.harp@adventiumlabs.org \
    --cc=SELinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.