-----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
<[email protected]>
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-----
On Mon, 2009-03-02 at 11:58 -0500, Daniel J Walsh wrote:
> -----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
>
> <[email protected]>
>
> 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.
I'm willing to consider it, but it'll need a good name.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150