All of lore.kernel.org
 help / color / mirror / Atom feed
From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] TCP server howto
Date: Mon, 02 Mar 2009 11:58:02 -0500	[thread overview]
Message-ID: <49AC101A.50101@redhat.com> (raw)
In-Reply-To: <20090302153448.GH31276@fi.muni.cz>

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

Jan Kasprzak wrote:
> Dominick Grift wrote:
> : I think corenet_reserved_port() is what you are looking for.
> : 
> 	Thanks for the hint. It is _almost_ exactly as you wrote,
> except:
> 
> : # Declarations
> : 
> : type my_port_t;
> : corenet_reserved_port(my_port_t)
> : 
> : # Policy
> : 
> : corenet_all_recvfrom_unlabeled($1)
> : corenet_all_recvfrom_netlabel($1)
> : corenet_tcp_sendrecv_generic_if($1)
> : corenet_tcp_sendrecv_generic_node($1)
> : corenet_tcp_sendrecv_all_ports($1)
> - corenet_tcp_bind_generic_node($1)
> + corenet_tcp_bind_inadrr_any_node($1)
> 
> : allow $1 my_port_t:tcp_socket name_bind;
> 
> + allow $1 self:capability net_bind_service;
> + allow $1 self:tcp_socket create_stream_socket_perms;
> 
> : #EOF
> : 
> : sudo semanage port -a -t my_port_t -p tcp 40
> 
> 	I would however like to have a really-high-level macro (or two)
> to do the above - I guess this is what many users would like to do
> - saying "this context belongs to my port", and "this domain can run
> a TCP server on this port". The similar way how the files_pid_file()
> and files_pid_filetrans() macros allow for the
> "I want to have my own PID file in /var/run" case.
> 
> 	Would it be acceptable to submit this as a patch for inclusion
> in the upstream policy?
> 
> 	I would like to have other things included upstream as well - for
> example, now I have a policy bits for Perl: file contexts for
> /usr/bin/perl* and /usr/lib{,64}/perl5/*, and an interface macro for saying
> "this domain can run Perl scripts".  
> 
> 	Thanks,
> 
> -Yenya
> 

Yenya, take this discussion to the refpolicy list

<refpolicy@oss.tresys.com>

Better to discuss it there.  I think having a higher level template for
creating a tcp or udp port would not be a bad idea.  See what upstream
thinks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmsDzYACgkQrlYvE4MpobNJHwCfZ5YbOsiYpBATkbTZyCqkZWh+
wGUAn1qN1EySr3iW5Pn4TO8aDrhJKZRA
=+xoQ
-----END PGP SIGNATURE-----

       reply	other threads:[~2009-03-02 16:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090227230224.GF30997@fi.muni.cz>
     [not found] ` <1235817998.11365.12.camel@notebook1.grift.internal>
     [not found]   ` <20090302153448.GH31276@fi.muni.cz>
2009-03-02 16:58     ` Daniel J Walsh [this message]
2009-03-05 14:23       ` [refpolicy] TCP server howto Christopher J. PeBenito

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=49AC101A.50101@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=refpolicy@oss.tresys.com \
    /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.