On Tue, 2009-02-24 at 10:33 -0500, Paul Moore wrote: > On Tuesday 24 February 2009 10:11:56 am chanson@xxxxxxxxxxxxx wrote: > > Hi Paul, > > > > Is there any reason we can't utilize the new interfaces to handle the > > unlabeled_t lines in the constraints? I'm not a real big fan of putting > > direct types into the constraints. > > Convention and consistency with the other network constraints. I suppose this > is really a judgment call because what is the real difference between using > direct types and simply loading up the types with the MLS > overrides/attributes? The "unlabeled_t" type really is special and it seems > cleaner to me to use it directly in the constraints rather than adding a bunch > of attributes to it. There would also be a behavior change with the netif:egress and node:sendto permissions. Though I'm not sure it would matter in this case, I don't think doing something similar for the other two constraints that currently have explicit unlabeled_t references would work. I'm fine with the explicit references for now. If someone can make a patch that removes all the explicit references in a reasonable way, then I'd be interested. > > > -----Original Message----- > > > From: refpolicy-bounces@xxxxxxxxxxxxxx > > > [mailto:refpolicy-bounces@xxxxxxxxxxxxxx] On Behalf Of Paul Moore > > > Sent: Friday, February 20, 2009 4:03 PM > > > To: selinux@xxxxxxxxxxxxx; refpolicy@xxxxxxxxxxxxxx > > > Subject: [refpolicy] [PATCH v2] refpolicy: Add missing > > > network related MLSconstraints > > > > > > Add MLS constraints for several network related access > > > controls including the new ingress/egress controls and the > > > older Secmark controls. Based on the following post to the > > > SELinux Reference Policy mailing list: > > > > > > * http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html > > > > > > Signed-off-by: Paul Moore <paul.moore@xxxxxx> > > > > > > --- > > > policy/mls | 45 > > > +++++++++++++++++++++++++++++++++++++++++++ > > > policy/modules/kernel/mls.if | 42 > > > ++++++++++++++++++++++++++++++++++++++++ > > > policy/modules/kernel/mls.te | 2 + > > > 3 files changed, 89 insertions(+) > > > > > > Index: refpolicy_svn_repo/policy/mls > > > =================================================================== > > > --- refpolicy_svn_repo.orig/policy/mls > > > +++ refpolicy_svn_repo/policy/mls > > > @@ -295,8 +295,53 @@ mlsconstrain { netif node } { tcp_send u > > > # these access vectors have no MLS restrictions # node enforce_dest > > > > > > +# > > > +# MLS policy for the network ingress/egress controls # > > > + > > > +# the netif ingress/egress ops, the ingress permission is a "write" > > > +operation # because the subject in this particular case is > > > the remote > > > +domain which is # writing data out the network interface which is > > > +acting as the object mlsconstrain { netif } { ingress } > > > + ((( l1 dom l2 ) and ( l1 domby h2 )) or > > > + ( t1 == mlsnetinbound ) or > > > + ( t1 == unlabeled_t )); > > > +mlsconstrain { netif } { egress } > > > + ((( l1 dom l2 ) and ( l1 domby h2 )) or > > > + ( t1 == mlsnetoutbound )); > > > > > > +# the node recvfrom/sendto ops, the recvfrom permission is a "write" > > > +operation # because the subject in this particular case is > > > the remote > > > +domain which is # writing data out the network node which is > > > acting as > > > +the object mlsconstrain { node } { recvfrom } > > > + ((( l1 dom l2 ) and ( l1 domby h2 )) or > > > + ( t1 == mlsnetinbound ) or > > > + ( t1 == unlabeled_t )); > > > +mlsconstrain { node } { sendto } > > > + ((( l1 dom l2 ) and ( l1 domby h2 )) or > > > + ( t1 == mlsnetoutbound )); > > > > > > +# the forward ops, the forward_in permission is a "write" operation > > > +because the # subject in this particular case is the remote domain > > > +which is writing data # to the network with a secmark label, > > > the object > > > +in this case mlsconstrain { packet } { forward_in } > > > + ((( l1 dom l2 ) and ( l1 domby h2 )) or > > > + ( t1 == mlsnetinbound ) or > > > + ( t1 == unlabeled_t )); > > > +mlsconstrain { packet } { forward_out } > > > + ((( l1 dom l2 ) and ( l1 domby h2 )) or > > > + ( t1 == mlsnetoutbound ) or > > > + ( t1 == unlabeled_t )); > > > + > > > +# > > > +# MLS policy for the secmark and peer controls # > > > + > > > +# the peer/packet recv op > > > +mlsconstrain { peer packet } { recv } > > > + (( l1 dom l2 ) or > > > + (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or > > > + ( t1 == mlsnetread )); > > > > > > # > > > # MLS policy for the process class > > > Index: refpolicy_svn_repo/policy/modules/kernel/mls.if > > > =================================================================== > > > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if > > > +++ refpolicy_svn_repo/policy/modules/kernel/mls.if > > > @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',` > > > > > > ######################################## > > > ## <summary> > > > +## Make specified domain trusted to > > > +## write inbound packets regardless of the > > > +## network's or node's MLS range. > > > +## </summary> > > > +## <param name="domain"> > > > +## <summary> > > > +## Domain allowed access. > > > +## </summary> > > > +## </param> > > > +## <rolecap/> > > > +# > > > +interface(`mls_net_inbound_all_levels',` > > > + gen_require(` > > > + attribute mlsnetinbound; > > > + ') > > > + > > > + typeattribute $1 mlsnetinbound; > > > +') > > > + > > > +######################################## > > > +## <summary> > > > +## Make specified domain trusted to > > > +## write outbound packets regardless of the > > > +## network's or node's MLS range. > > > +## </summary> > > > +## <param name="domain"> > > > +## <summary> > > > +## Domain allowed access. > > > +## </summary> > > > +## </param> > > > +## <rolecap/> > > > +# > > > +interface(`mls_net_outbound_all_levels',` > > > + gen_require(` > > > + attribute mlsnetoutbound; > > > + ') > > > + > > > + typeattribute $1 mlsnetoutbound; > > > +') > > > + > > > +######################################## > > > +## <summary> > > > ## Make specified domain MLS trusted > > > ## for reading from System V IPC objects > > > ## up to its clearance. > > > Index: refpolicy_svn_repo/policy/modules/kernel/mls.te > > > =================================================================== > > > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te > > > +++ refpolicy_svn_repo/policy/modules/kernel/mls.te > > > @@ -22,6 +22,8 @@ attribute mlsnetwriteranged; attribute > > > mlsnetupgrade; attribute mlsnetdowngrade; attribute mlsnetrecvall; > > > +attribute mlsnetinbound; > > > +attribute mlsnetoutbound; > > > > > > attribute mlsipcread; > > > attribute mlsipcreadtoclr; > > > > > > -- > > > paul moore > > > linux @ hp > > > > > > _______________________________________________ > > > refpolicy mailing list > > > refpolicy@xxxxxxxxxxxxxx > > > http://oss.tresys.com/mailman/listinfo/refpolicy > -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
