secmark integration

secmark integration

[James Morris]

Following some discussion of secmark integration at the developer summit, 
one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
to have a separate table for managing the secmark rules.

This is technically possible (and we could also look at adding hooks for 
the load_policy permission to be called for manipulating rules in this 
table), but probably difficult to justify upstream: you should only do 
something in the kernel if it can't be done in userspace.

I think we can make a good argument, though, based on it being for MAC 
rules rather than DAC, in that the _type_ of security being managed is 
fundamentally different, and that the table is likely being managed in 
conjunction with SELinux policy.

Is there a consensus, particularly from distro folk, that having a 
separate table would be of great benefit ?  I can post a rudimentary patch 
soon, if needed.

Further issues that I heard mentioned:

a) Flush behavior is inverted: flush the iptables rules, and networking 
   stops, as the packets are not labeled anymore.
    - This can be managed if the security table is managed via some tool,
      e.g. flip compat_net on with no compat rules, or implement a single 
      rule to label all packets with some special bypass label.

b) Confusing interactions with manual table management and various 3rd 
   party tools.
    - Firstly, we either use obvious chain names (e.g. 
      '__SELINUX_AUTOGENERATED') to indicate to the admin that they 
      shouldn't mess with them manually, or as suggested, use an entirely
      separate table.
    - How many distros have standard or blessed tools for managing the 
      firewall?  Can we get secmark support integrated into these 
      upstream?  I think if we architect this so that the heavy lifting is 
      done via a library, the firewall tools can just call the 
      appropriate API hooks as needed.
    - I think we need SELinux callouts in the iptables init script, as
      save/restore/start/stop actions are now manipulating MAC security.  
      Perhaps we completely separate SELinux control of tables so that the 
      standard script doesn't touch them ?

c) User-customization of policy.
    - I think we need to abstract this with a high level tool, starting 
      with a common default, some common recipes and then increasingly 
      low-level means to maintain modifications.

d) Some users do not want the iptables module loaded ?  (for how many 
   people is this an issue ?) I wonder if they know that SELinux is 
   already hooked into the netfilter framework.  We could try and convince 
   them to allow it, and as a worst case, provide a switch to enable 
   compat_net with no rules.

e) Management and bundling of secmark rules with policy.
    - Well, we already have separate policy with file_contexts, and
      separate filesystem labeling and management mechanisms, integrated
      widely into the system.

As far as management of the rules goes, the vast majority of packets will 
be 'related' to an existing connection, and this should be the first rule, 
which causes an immediate jump out of the table.  The next most common 
will be SYN packets for the most common services on the system (e.g. to 
port 80), and rules for these services should be ordered appropriately to 
minimize the amount of table traversal.  This could even be monitored by 
the admin tool and allow the admin to order the rules based on how often 
they're hit.

We can also follow the targeted policy model, where only targeted domains 
have rules requiring packets with specific labels.


Comments?

What other issues need to be resolved for this ?


- James
-- 
James Morris
<jmorris@namei.org>

--
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: secmark integration

[Karl MacMillan]

On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> Following some discussion of secmark integration at the developer summit, 
> one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> to have a separate table for managing the secmark rules.
> 
> This is technically possible (and we could also look at adding hooks for 
> the load_policy permission to be called for manipulating rules in this 
> table), but probably difficult to justify upstream: you should only do 
> something in the kernel if it can't be done in userspace.
> 
> I think we can make a good argument, though, based on it being for MAC 
> rules rather than DAC, in that the _type_ of security being managed is 
> fundamentally different, and that the table is likely being managed in 
> conjunction with SELinux policy.
> 
> Is there a consensus, particularly from distro folk, that having a 
> separate table would be of great benefit ?  I can post a rudimentary patch 
> soon, if needed.
> 

Is this really needed as long as the distro provides a way to customize
the iptables rules?

> Further issues that I heard mentioned:
> 
> a) Flush behavior is inverted: flush the iptables rules, and networking 
>    stops, as the packets are not labeled anymore.
>     - This can be managed if the security table is managed via some tool,
>       e.g. flip compat_net on with no compat rules, or implement a single 
>       rule to label all packets with some special bypass label.
> 

I think that updating the iptables scripts to flip a boolean that allows
unlabeled network traffic would work here.

> b) Confusing interactions with manual table management and various 3rd 
>    party tools.
>     - Firstly, we either use obvious chain names (e.g. 
>       '__SELINUX_AUTOGENERATED') to indicate to the admin that they 
>       shouldn't mess with them manually, or as suggested, use an entirely
>       separate table.
>     - How many distros have standard or blessed tools for managing the 
>       firewall?  Can we get secmark support integrated into these 
>       upstream?  I think if we architect this so that the heavy lifting is 
>       done via a library, the firewall tools can just call the 
>       appropriate API hooks as needed.

None?

>     - I think we need SELinux callouts in the iptables init script, as
>       save/restore/start/stop actions are now manipulating MAC security.  
>       Perhaps we completely separate SELinux control of tables so that the 
>       standard script doesn't touch them ?
> 
> c) User-customization of policy.
>     - I think we need to abstract this with a high level tool, starting 
>       with a common default, some common recipes and then increasingly 
>       low-level means to maintain modifications.
> 

At least initially, I think that it is fine for users to use whatever
means they would normally use to modify the secmark rules. Essentially
the workflow would be:

1) Disable default unlabeled_t network traffic for the daemon or in
general (presumably through a boolean).

2) Create a module with the types and rules that you need. Assuming a
global boolean, something like (Dan / Chris - comments about this are
needed):

type http_packet_t;

# Allow all daemons except apache to use unlabeled packets. We
# need a networkdaemon attribute or some type interface here.
allow { daemon -httpd_t } unlabeled_t : packet { send recv };

allow httpd_t http_packet_t : packet { send recv };

3) Create some secmark rules to mark http packets as http_packet_t.

With some documentation, I really don't think this is that hard. After
we experiment with this higher-level tools can be created.

> d) Some users do not want the iptables module loaded ?  (for how many 
>    people is this an issue ?) I wonder if they know that SELinux is 
>    already hooked into the netfilter framework.  We could try and convince 
>    them to allow it, and as a worst case, provide a switch to enable 
>    compat_net with no rules.
> 

Or presumably if they don't use iptables they won't care about secmark
either.

> e) Management and bundling of secmark rules with policy.
>     - Well, we already have separate policy with file_contexts, and
>       separate filesystem labeling and management mechanisms, integrated
>       widely into the system.
> 

Which is now turned off. I think that for many people the port binding
controls are enough. For the rest I think we should start with custom
secmark rules. The generated rules from policy are too restrictive and
too hard to customize. The whole goal was to allow people to use
iptables to classify their network traffic - forcing that labeling into
the policy destroys that flexibility. So keeping them separate is, I
think, the right answer.

> As far as management of the rules goes, the vast majority of packets will 
> be 'related' to an existing connection, and this should be the first rule, 
> which causes an immediate jump out of the table.  The next most common 
> will be SYN packets for the most common services on the system (e.g. to 
> port 80), and rules for these services should be ordered appropriately to 
> minimize the amount of table traversal.  This could even be monitored by 
> the admin tool and allow the admin to order the rules based on how often 
> they're hit.
> 
> We can also follow the targeted policy model, where only targeted domains 
> have rules requiring packets with specific labels.
> 

See above - I think that custom rules are sufficient.

Karl


--
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: secmark integration

[Eric Paris]

On Fri, 2007-03-30 at 15:47 -0400, Karl MacMillan wrote:
> On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> > Following some discussion of secmark integration at the developer summit, 
> > one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> > to have a separate table for managing the secmark rules.
> > 
> > This is technically possible (and we could also look at adding hooks for 
> > the load_policy permission to be called for manipulating rules in this 
> > table), but probably difficult to justify upstream: you should only do 
> > something in the kernel if it can't be done in userspace.
> > 
> > I think we can make a good argument, though, based on it being for MAC 
> > rules rather than DAC, in that the _type_ of security being managed is 
> > fundamentally different, and that the table is likely being managed in 
> > conjunction with SELinux policy.
> > 
> > Is there a consensus, particularly from distro folk, that having a 
> > separate table would be of great benefit ?  I can post a rudimentary patch 
> > soon, if needed.
> > 
> 
> Is this really needed as long as the distro provides a way to customize
> the iptables rules?

It's not just that.  The reason a new table was proposed was because
people may want to iptables -F and flush their rules.  If the secmark
stuff is on the main tables (filter and nat) that people use it will get
blown away and there will be no automation of a boolean setting you talk
about later.


--
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: secmark integration

[Karl MacMillan]

On Fri, 2007-03-30 at 16:25 -0400, Eric Paris wrote:
> On Fri, 2007-03-30 at 15:47 -0400, Karl MacMillan wrote:
> > On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> > > Following some discussion of secmark integration at the developer summit, 
> > > one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> > > to have a separate table for managing the secmark rules.
> > > 
> > > This is technically possible (and we could also look at adding hooks for 
> > > the load_policy permission to be called for manipulating rules in this 
> > > table), but probably difficult to justify upstream: you should only do 
> > > something in the kernel if it can't be done in userspace.
> > > 
> > > I think we can make a good argument, though, based on it being for MAC 
> > > rules rather than DAC, in that the _type_ of security being managed is 
> > > fundamentally different, and that the table is likely being managed in 
> > > conjunction with SELinux policy.
> > > 
> > > Is there a consensus, particularly from distro folk, that having a 
> > > separate table would be of great benefit ?  I can post a rudimentary patch 
> > > soon, if needed.
> > > 
> > 
> > Is this really needed as long as the distro provides a way to customize
> > the iptables rules?
> 
> It's not just that.  The reason a new table was proposed was because
> people may want to iptables -F and flush their rules.  If the secmark
> stuff is on the main tables (filter and nat) that people use it will get
> blown away and there will be no automation of a boolean setting you talk
> about later.
> 

If we add the custom table won't we need a way to flush that? If so,
would we add an iptables --no-really-flush command? If we want to
preserve the iptables with no rules means all traffic is allowed
semantic we need to somehow coordinate rule removal with the policy.
Options I see:

1) Change iptables to flip a boolean. This sucks because we need some
way for iptables to know which boolean to flip.

2) Have the kernel mechanism stop enforcement of rules that rely on
secmark when the tables are empty / flushed.

3) Tell people to not do this - instead use distro scripts with
integration. This seems unlikely to work.

So, what about 2?

Karl


--
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: secmark integration

[Eric Paris]

On Fri, 2007-03-30 at 16:36 -0400, Karl MacMillan wrote:
> On Fri, 2007-03-30 at 16:25 -0400, Eric Paris wrote:
> > On Fri, 2007-03-30 at 15:47 -0400, Karl MacMillan wrote:
> > > On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> > > > Following some discussion of secmark integration at the developer summit, 
> > > > one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> > > > to have a separate table for managing the secmark rules.
> > > > 
[snip]
> > > > Is there a consensus, particularly from distro folk, that having a 
> > > > separate table would be of great benefit ?  I can post a rudimentary patch 
> > > > soon, if needed.
> > > > 
> > > 
> > > Is this really needed as long as the distro provides a way to customize
> > > the iptables rules?
> > 
> > It's not just that.  The reason a new table was proposed was because
> > people may want to iptables -F and flush their rules.  If the secmark
> > stuff is on the main tables (filter and nat) that people use it will get
> > blown away and there will be no automation of a boolean setting you talk
> > about later.
> > 
> 
> If we add the custom table won't we need a way to flush that? 

Sure it would still be flushable, just not how people normally go about
turning off iptables rules.  Now to flush rules users would

iptables -F
iptables -F -t nat

to get the secmark stuff they would also have to do
iptables -F -t secmark

> If so,
> would we add an iptables --no-really-flush command? If we want to
> preserve the iptables with no rules means all traffic is allowed
> semantic we need to somehow coordinate rule removal with the policy.

I agree that coordination between rule removal and policy unlabeled_t
boolean flipping is a good thing, but having the labeling rules on their
own table would allow people and tools to deal with the firewall as they
always have and not 'accidentally' mess up the secmark rules.  If
iptables people are already used to having to explicitly work on the nat
table i don't see why they would have have a problem working explicitly
on the secmark table for local network labeling.

> Options I see:
> 
> 1) Change iptables to flip a boolean. This sucks because we need some
> way for iptables to know which boolean to flip.

something tells me this is not upstreamable.  Would need to be a tool on
top of iptables, which then some people wouldn't want to use...

> 
> 2) Have the kernel mechanism stop enforcement of rules that rely on
> secmark when the tables are empty / flushed.

this one isn't so easy.  i don't like the idea of selective enforcement
although it does maintain the notion of 'allow when off' that users
expect from iptables.  Probably would be better as 'deny unlabeled_t if
some other label may exist.'  That would also have the implication that
setting up labeling of some sort of one domain would then disable the
unlabeled for every other domain.  Nothing in the secmark table is going
to say that httpd_packet_t is only used by the httpd_t and squid_t
domain.  How can the kernel know that it shouldn't enforce things for
autofs_t but should for those 2.  No no, i'm liking selective
enforcement in kernel less and less.

> 
> 3) Tell people to not do this - instead use distro scripts with
> integration. This seems unlikely to work.

oh yeah, tell people to only use system-config-network instead of being
like me and writing my own huge scripts.  you're right, that'll happen
</sarcasm>.

4) Find some guy who works in userspace and get him to write a tool that
will allow you to fill in some blanks and it will create the policy,
iptables labeling rule, and boolean settings for you.  If someone does
go back and explicitly break the secmark table its their own fault and
they get to hold the pieces.  If they use this new tool that someone
*cough*karl*cough* writes then everything works.  When they flush the
secmark rules in this tool it cleans up the policy, the custom table,
and sets the booleans.  

****

Getting secmark to work properly is a 3 step process right?  Define a
new type and allow the domain in question to use that type in a policy
module.  Disable the boolean in policy that already lets that domain use
the unlabeled_t type.  Create a secmark rule to label network traffic
with the type you defined in part1.

Maybe at some point we can ship labeling rules by default (and i don't
know if these belong with the other 'normal' firewall rules as opposed
to a seperate init script which just sets the secmark rules) which match
little other than we already match in the name_{bind,connect} checks and
can eliminate the boolean step.  But for now it seems that making it so
that a user won't accidentally shoot themselves in the foot and products
like 'webmin' can't hurt anything would be a good step....

-Eric


--
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: secmark integration

[James Morris]

On Fri, 30 Mar 2007, Eric Paris wrote:

> > Is this really needed as long as the distro provides a way to customize
> > the iptables rules?
> 
> It's not just that.  The reason a new table was proposed was because
> people may want to iptables -F and flush their rules.  If the secmark
> stuff is on the main tables (filter and nat) that people use it will get
> blown away and there will be no automation of a boolean setting you talk
> about later.

I think there's also a good case for a separate table on the basis that 
the rules are part of a separate administrative realm (e.g. MAC, rather 
than DAC) and should be maintained separately.  We could also look at 
adding an LSM hook for rules being manipulated in this table (perhaps 
called 'security' to be more general).

Note that there may be tools which parse /proc/net/ip_tables_names when 
flushing (which the LSM hook would possibly help with in terms of stopping 
MAC policy from being modified without the correct authorization).

It still may be difficult to sell upstream, so we'd need more feedback 
from the distro folk possibly after some experimentation.


- James
-- 
James Morris
<jmorris@namei.org>

--
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: secmark integration

[Daniel J Walsh]

James Morris wrote:
> On Fri, 30 Mar 2007, Eric Paris wrote:
>
>   
>>> Is this really needed as long as the distro provides a way to customize
>>> the iptables rules?
>>>       
>> It's not just that.  The reason a new table was proposed was because
>> people may want to iptables -F and flush their rules.  If the secmark
>> stuff is on the main tables (filter and nat) that people use it will get
>> blown away and there will be no automation of a boolean setting you talk
>> about later.
>>     
>
> I think there's also a good case for a separate table on the basis that 
> the rules are part of a separate administrative realm (e.g. MAC, rather 
> than DAC) and should be maintained separately.  We could also look at 
> adding an LSM hook for rules being manipulated in this table (perhaps 
> called 'security' to be more general).
>
> Note that there may be tools which parse /proc/net/ip_tables_names when 
> flushing (which the LSM hook would possibly help with in terms of stopping 
> MAC policy from being modified without the correct authorization).
>
> It still may be difficult to sell upstream, so we'd need more feedback 
> from the distro folk possibly after some experimentation.
>
>
> - James
>   

I like karl suggestion.  service iptables stop , flips boolean that says 
all domains support unlabeled_t:packet.  service iptables start turns 
that off.

Currently there is a boolean in Rawhide allow_unlabeled_packets.

tunable_policy(`allow_unlabeled_packets',`
        kernel_sendrecv_unlabeled_association(domain)
        corenet_sendrecv_unlabeled_packets(domain)
')
These lines endup generating these rules
        allow domain unlabeled_t:packet { send recv };
        allow domain $1 unlabeled_t:association { sendto recvfrom };

This boolean defaults to true.


I think as soon as FC7 ships we can start experimenting in Rawhide and 
build a couple of scripts/modules that people could use to take 
advantage of secmark.

--
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: secmark integration

[Paul Moore]

On Friday, March 30 2007 10:09:45 pm James Morris wrote:
> On Fri, 30 Mar 2007, Eric Paris wrote:
> > > Is this really needed as long as the distro provides a way to customize
> > > the iptables rules?
> >
> > It's not just that.  The reason a new table was proposed was because
> > people may want to iptables -F and flush their rules.  If the secmark
> > stuff is on the main tables (filter and nat) that people use it will get
> > blown away and there will be no automation of a boolean setting you talk
> > about later.
>
> I think there's also a good case for a separate table on the basis that
> the rules are part of a separate administrative realm (e.g. MAC, rather
> than DAC) and should be maintained separately.  We could also look at
> adding an LSM hook for rules being manipulated in this table (perhaps
> called 'security' to be more general).

I agree that if we add a new table it should be a generic security/lsm table.  
While presently only secmark would make use of it; the iptables in/out/fwd 
checks for externally labeled packets discussed most recently at the 
developer's summit could also make use of the same table for the same reasons 
as secmark.

-- 
paul moore
linux security @ hp

--
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: secmark integration

[Eric Paris]

On Mon, 2007-04-02 at 10:45 -0400, Daniel J Walsh wrote:
> James Morris wrote:
> > On Fri, 30 Mar 2007, Eric Paris wrote:
> >
> >   
> >>> Is this really needed as long as the distro provides a way to customize
> >>> the iptables rules?
> >>>       
> >> It's not just that.  The reason a new table was proposed was because
> >> people may want to iptables -F and flush their rules.  If the secmark
> >> stuff is on the main tables (filter and nat) that people use it will get
> >> blown away and there will be no automation of a boolean setting you talk
> >> about later.
> >>     
> >
> > I think there's also a good case for a separate table on the basis that 
> > the rules are part of a separate administrative realm (e.g. MAC, rather 
> > than DAC) and should be maintained separately.  We could also look at 
> > adding an LSM hook for rules being manipulated in this table (perhaps 
> > called 'security' to be more general).
> >
> > Note that there may be tools which parse /proc/net/ip_tables_names when 
> > flushing (which the LSM hook would possibly help with in terms of stopping 
> > MAC policy from being modified without the correct authorization).
> >
> > It still may be difficult to sell upstream, so we'd need more feedback 
> > from the distro folk possibly after some experimentation.
> >
> >
> > - James
> >   
> 
> I like karl suggestion.  service iptables stop , flips boolean that says 
> all domains support unlabeled_t:packet.  service iptables start turns 
> that off.
> 
> Currently there is a boolean in Rawhide allow_unlabeled_packets.
> 
> tunable_policy(`allow_unlabeled_packets',`
>         kernel_sendrecv_unlabeled_association(domain)
>         corenet_sendrecv_unlabeled_packets(domain)
> ')
> These lines endup generating these rules
>         allow domain unlabeled_t:packet { send recv };
>         allow domain $1 unlabeled_t:association { sendto recvfrom };
> 
> This boolean defaults to true.
> 
> 
> I think as soon as FC7 ships we can start experimenting in Rawhide and 
> build a couple of scripts/modules that people could use to take 
> advantage of secmark.

Good idea.  Can anyone help me come up with any way in which we can use
secmark 'by default' and gain any greater protections than we already
have with name_{bind,connect}

Seems to me that port number is the only thing we can label based on for
everyone out of the box.  Any more complex labeling scheme is going to
require network specific information, right?

-Eric


--
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: secmark integration

[Christopher J. PeBenito]

On Mon, 2007-04-02 at 10:55 -0400, Eric Paris wrote:
> On Mon, 2007-04-02 at 10:45 -0400, Daniel J Walsh wrote:
> > James Morris wrote:
> > > On Fri, 30 Mar 2007, Eric Paris wrote:
> > >
> > >   
> > >>> Is this really needed as long as the distro provides a way to customize
> > >>> the iptables rules?
> > >>>       
> > >> It's not just that.  The reason a new table was proposed was because
> > >> people may want to iptables -F and flush their rules.  If the secmark
> > >> stuff is on the main tables (filter and nat) that people use it will get
> > >> blown away and there will be no automation of a boolean setting you talk
> > >> about later.
> > >>     
> > >
> > > I think there's also a good case for a separate table on the basis that 
> > > the rules are part of a separate administrative realm (e.g. MAC, rather 
> > > than DAC) and should be maintained separately.  We could also look at 
> > > adding an LSM hook for rules being manipulated in this table (perhaps 
> > > called 'security' to be more general).
> > >
> > > Note that there may be tools which parse /proc/net/ip_tables_names when 
> > > flushing (which the LSM hook would possibly help with in terms of stopping 
> > > MAC policy from being modified without the correct authorization).
> > >
> > > It still may be difficult to sell upstream, so we'd need more feedback 
> > > from the distro folk possibly after some experimentation.
> > >
> > >
> > > - James
> > >   
> > 
> > I like karl suggestion.  service iptables stop , flips boolean that says 
> > all domains support unlabeled_t:packet.  service iptables start turns 
> > that off.
> > 
> > Currently there is a boolean in Rawhide allow_unlabeled_packets.
> > 
> > tunable_policy(`allow_unlabeled_packets',`
> >         kernel_sendrecv_unlabeled_association(domain)
> >         corenet_sendrecv_unlabeled_packets(domain)
> > ')
> > These lines endup generating these rules
> >         allow domain unlabeled_t:packet { send recv };
> >         allow domain $1 unlabeled_t:association { sendto recvfrom };
> > 
> > This boolean defaults to true.
> > 
> > 
> > I think as soon as FC7 ships we can start experimenting in Rawhide and 
> > build a couple of scripts/modules that people could use to take 
> > advantage of secmark.
> 
> Good idea.  Can anyone help me come up with any way in which we can use
> secmark 'by default' and gain any greater protections than we already
> have with name_{bind,connect}
> 
> Seems to me that port number is the only thing we can label based on for
> everyone out of the box.  Any more complex labeling scheme is going to
> require network specific information, right?

Right.  Refpolicy already can create a set of iptables rules based on
the ports defined in the policy, but its not currently shipped (which
was decided at the summit).

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secmark integration

[James Morris]

On Mon, 2 Apr 2007, Eric Paris wrote:

> Seems to me that port number is the only thing we can label based on for
> everyone out of the box.  Any more complex labeling scheme is going to
> require network specific information, right?

For gateways & externally facing systems, we could use types for the 
interfaces, e.g. external_netif, internal_netif and have a loadable module 
or something which differentiates between internal and external traffic.



-- 
James Morris
<jmorris@namei.org>

--
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: secmark integration

[Joshua Brindle]

James Morris wrote:
> On Mon, 2 Apr 2007, Eric Paris wrote:
>
>   
>> Seems to me that port number is the only thing we can label based on for
>> everyone out of the box.  Any more complex labeling scheme is going to
>> require network specific information, right?
>>     
>
> For gateways & externally facing systems, we could use types for the 
> interfaces, e.g. external_netif, internal_netif and have a loadable module 
> or something which differentiates between internal and external traffic.
>
>   
Unfortunately it isn't nearly this easy. If your security goal was just 
to differentiate internal and external traffic it would work fine but 
you'd be losing all granularity of port based access control. To do this 
with the refpolicy model of labeling based on service ports you'd have 
to replicate the entire corenetwork module with internal and external 
types and then fix all the service domains to be able to use the 
appropriate ones. I just don't think this scales.


--
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: secmark integration

[Karl MacMillan]

On Mon, 2007-04-02 at 15:15 +0000, Christopher J. PeBenito wrote:
> On Mon, 2007-04-02 at 10:55 -0400, Eric Paris wrote:
> > 
> > Good idea.  Can anyone help me come up with any way in which we can use
> > secmark 'by default' and gain any greater protections than we already
> > have with name_{bind,connect}
> > 
> > Seems to me that port number is the only thing we can label based on for
> > everyone out of the box.  Any more complex labeling scheme is going to
> > require network specific information, right?
> 
> Right.  Refpolicy already can create a set of iptables rules based on
> the ports defined in the policy, but its not currently shipped (which
> was decided at the summit).
> 

I don't think that there are particularly good restrictions that we can
do out of the box. I think that we should instead focus on making it
fairly easy to do customization with some documentation / recipes that
people can follow.

To that end, Chris / Dan, can you comment on my policy example? What I
posted doesn't exactly work now and I would like to know what the
suggested method for allowing almost all network facing daemons to
receive unlabeled_t packets is going to be.

Karl


--
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: secmark integration

[Karl MacMillan]

On Fri, 2007-03-30 at 17:47 -0400, Eric Paris wrote:
> On Fri, 2007-03-30 at 16:36 -0400, Karl MacMillan wrote:
> > On Fri, 2007-03-30 at 16:25 -0400, Eric Paris wrote:
> > > On Fri, 2007-03-30 at 15:47 -0400, Karl MacMillan wrote:
> > > > On Mon, 2007-03-19 at 10:57 -0400, James Morris wrote:
> > > > > Following some discussion of secmark integration at the developer summit, 
> > > > > one of the ideas proposed by Joshua (IIRC) was that it would be desirable 
> > > > > to have a separate table for managing the secmark rules.
> > > > > 
> [snip]
> > > > > Is there a consensus, particularly from distro folk, that having a 
> > > > > separate table would be of great benefit ?  I can post a rudimentary patch 
> > > > > soon, if needed.
> > > > > 
> > > > 
> > > > Is this really needed as long as the distro provides a way to customize
> > > > the iptables rules?
> > > 
> > > It's not just that.  The reason a new table was proposed was because
> > > people may want to iptables -F and flush their rules.  If the secmark
> > > stuff is on the main tables (filter and nat) that people use it will get
> > > blown away and there will be no automation of a boolean setting you talk
> > > about later.
> > > 
> > 
> > If we add the custom table won't we need a way to flush that? 
> 
> Sure it would still be flushable, just not how people normally go about
> turning off iptables rules.  Now to flush rules users would
> 
> iptables -F
> iptables -F -t nat
> 
> to get the secmark stuff they would also have to do
> iptables -F -t secmark
> 

That sounds fine to me, but James mentioned that the upstream acceptance
might be hard. So how do we experiment in the short term? Just don't
worry about rules getting flushed?


<snip>

> 
> 4) Find some guy who works in userspace and get him to write a tool that
> will allow you to fill in some blanks and it will create the policy,
> iptables labeling rule, and boolean settings for you.

I don't think this is a good idea for the initial rollout of secmark.
Again, the whole idea is to use the power of iptables for labeling. If
you hide that behind higher-level abstractions I think that people will
just be frustrated because they won't be able to accomplish what they
want.

Writing iptables rules is *not* the problem for acceptance. Just having
a clear way to use secmark is enough initially.
After that, we can get a good idea of what types of things people want
out of secmark and can put some tools on top.

<snip>

> 
> Maybe at some point we can ship labeling rules by default (and i don't
> know if these belong with the other 'normal' firewall rules as opposed
> to a seperate init script which just sets the secmark rules) which match
> little other than we already match in the name_{bind,connect} checks and
> can eliminate the boolean step.

Why would we? The name_* checks are effective at what they do and are
easily managed by semanage. I would rather push secmark towards things
that are currently hard to enforce (like separating traffic from two
nics).

>   But for now it seems that making it so
> that a user won't accidentally shoot themselves in the foot and products
> like 'webmin' can't hurt anything would be a good step....

Not certain that I agree. Let's make it usable for knowledgeable
sysadmins first and then try to wrap higher-level tools around this. If
it solves peoples problems they will use it with or without a gui.

Karl


--
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: secmark integration

[Karl MacMillan]

On Mon, 2007-04-02 at 13:14 -0400, Joshua Brindle wrote:
> James Morris wrote:
> > On Mon, 2 Apr 2007, Eric Paris wrote:
> >
> >   
> >> Seems to me that port number is the only thing we can label based on for
> >> everyone out of the box.  Any more complex labeling scheme is going to
> >> require network specific information, right?
> >>     
> >
> > For gateways & externally facing systems, we could use types for the 
> > interfaces, e.g. external_netif, internal_netif and have a loadable module 
> > or something which differentiates between internal and external traffic.
> >
> >   
> Unfortunately it isn't nearly this easy. If your security goal was just 
> to differentiate internal and external traffic it would work fine but 
> you'd be losing all granularity of port based access control. To do this 
> with the refpolicy model of labeling based on service ports you'd have 
> to replicate the entire corenetwork module with internal and external 
> types and then fix all the service domains to be able to use the 
> appropriate ones. I just don't think this scales.
> 

I think that controlling port binding plus separating the traffic with
secmark will be sufficient in most cases. There is no advantage to
replicating the port binding rules with secmark (except perhaps with
protocols that connect to random ports like nis or ftp).

I'd also suggest that corenetwork should be used primarily for the
name_[bind/connect] checks and push the rest of the network controls
into secmark rules and custom modules. That reduces the number of
iptables rules by default and reduces the customization needed in
corenetwork.

Again, pushing secmark labeling into the selinux policy destroys the
flexibility we gain with secmark and becomes a management nightmare.

Karl


--
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: secmark integration

[James Morris]

On Mon, 2 Apr 2007, Karl MacMillan wrote:

> That sounds fine to me, but James mentioned that the upstream acceptance
> might be hard. So how do we experiment in the short term? Just don't
> worry about rules getting flushed?

I can supply a patch which creates a new table, for experimental purposes.  
Perhaps someone (Eric?) could make a Fedora kernel rpm with the patch for 
testing only.


-- 
James Morris
<jmorris@namei.org>

--
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: secmark integration

[James Morris]

On Mon, 2 Apr 2007, Karl MacMillan wrote:

> I think that controlling port binding plus separating the traffic with
> secmark will be sufficient in most cases. There is no advantage to
> replicating the port binding rules with secmark (except perhaps with
> protocols that connect to random ports like nis or ftp).

There definitely is, as connection tracking will ensure that only packets 
which are valid for the connection are labeled appropriately, so you don't 
need open rules for ephemeral ports etc., as well as the tighter security 
in general.



- James
-- 
James Morris
<jmorris@namei.org>

--
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: secmark integration

[Karl MacMillan]

On Mon, 2007-04-02 at 15:47 -0400, James Morris wrote:
> On Mon, 2 Apr 2007, Karl MacMillan wrote:
> 
> > I think that controlling port binding plus separating the traffic with
> > secmark will be sufficient in most cases. There is no advantage to
> > replicating the port binding rules with secmark (except perhaps with
> > protocols that connect to random ports like nis or ftp).
> 
> There definitely is, as connection tracking will ensure that only packets 
> which are valid for the connection are labeled appropriately, so you don't 
> need open rules for ephemeral ports etc., as well as the tighter security 
> in general.
> 

I'm not arguing that secmark doesn't have some advantages, particularly
around connection tracking. What I'm saying is that controlling port
binding in the way we currently do is sufficient as a starting point.

Karl


--
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: secmark integration

[Christopher J. PeBenito]

On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> On Mon, 2007-04-02 at 15:15 +0000, Christopher J. PeBenito wrote:
> > On Mon, 2007-04-02 at 10:55 -0400, Eric Paris wrote:
> > > 
> > > Good idea.  Can anyone help me come up with any way in which we can use
> > > secmark 'by default' and gain any greater protections than we already
> > > have with name_{bind,connect}
> > > 
> > > Seems to me that port number is the only thing we can label based on for
> > > everyone out of the box.  Any more complex labeling scheme is going to
> > > require network specific information, right?
> > 
> > Right.  Refpolicy already can create a set of iptables rules based on
> > the ports defined in the policy, but its not currently shipped (which
> > was decided at the summit).
> > 
> 
> I don't think that there are particularly good restrictions that we can
> do out of the box. I think that we should instead focus on making it
> fairly easy to do customization with some documentation / recipes that
> people can follow.

I still think the set that refpolicy can generate is fine.  It provides
the default ports for services on all interfaces.  This is better than
almost unconfined as it is now.  The incoming connections rules mirror
the name_bind rules, and the outgoing connections mirrors the
name_connect rules.  Since UDP doesn't have a connect we can cover that
reasonably too.  Then we get the connection tracking on all these too.

> To that end, Chris / Dan, can you comment on my policy example? What I
> posted doesn't exactly work now and I would like to know what the
> suggested method for allowing almost all network facing daemons to
> receive unlabeled_t packets is going to be.

Actually, my current idea is to make a tunable for each domain that
networks.  If we were to go the negation route, it would be something
like this in corenetwork:

corenet_sendrecv_unlabeled_packets({ networking_domain -confined_networking_domain })

Then corenetwork would provide interfaces to gain these attributes.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secmark integration

[Karl MacMillan]

On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> > On Mon, 2007-04-02 at 15:15 +0000, Christopher J. PeBenito wrote:
> > > On Mon, 2007-04-02 at 10:55 -0400, Eric Paris wrote:
> > > > 
> > > > Good idea.  Can anyone help me come up with any way in which we can use
> > > > secmark 'by default' and gain any greater protections than we already
> > > > have with name_{bind,connect}
> > > > 
> > > > Seems to me that port number is the only thing we can label based on for
> > > > everyone out of the box.  Any more complex labeling scheme is going to
> > > > require network specific information, right?
> > > 
> > > Right.  Refpolicy already can create a set of iptables rules based on
> > > the ports defined in the policy, but its not currently shipped (which
> > > was decided at the summit).
> > > 
> > 
> > I don't think that there are particularly good restrictions that we can
> > do out of the box. I think that we should instead focus on making it
> > fairly easy to do customization with some documentation / recipes that
> > people can follow.
> 
> I still think the set that refpolicy can generate is fine.  It provides
> the default ports for services on all interfaces.  This is better than
> almost unconfined as it is now.  The incoming connections rules mirror
> the name_bind rules, and the outgoing connections mirrors the
> name_connect rules.  Since UDP doesn't have a connect we can cover that
> reasonably too.  Then we get the connection tracking on all these too.
> 

The problem is moving from this default to a customized version. How
will a packet type be redefined? Additive rules are fine, but changing
or removing rules is problematic.

Anyway - I thought that this decision was already made. Are people
wanting to discuss this again?

> > To that end, Chris / Dan, can you comment on my policy example? What I
> > posted doesn't exactly work now and I would like to know what the
> > suggested method for allowing almost all network facing daemons to
> > receive unlabeled_t packets is going to be.
> 
> Actually, my current idea is to make a tunable for each domain that
> networks.  If we were to go the negation route, it would be something
> like this in corenetwork:
> 
> corenet_sendrecv_unlabeled_packets({ networking_domain -confined_networking_domain })
> 
> Then corenetwork would provide interfaces to gain these attributes.

Is this actively being worked on?

Karl


--
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: secmark integration

[Daniel J Walsh]

Karl MacMillan wrote:
> On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
>   
>> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
>>     
>>> On Mon, 2007-04-02 at 15:15 +0000, Christopher J. PeBenito wrote:
>>>       
>>>> On Mon, 2007-04-02 at 10:55 -0400, Eric Paris wrote:
>>>>         
>>>>> Good idea.  Can anyone help me come up with any way in which we can use
>>>>> secmark 'by default' and gain any greater protections than we already
>>>>> have with name_{bind,connect}
>>>>>
>>>>> Seems to me that port number is the only thing we can label based on for
>>>>> everyone out of the box.  Any more complex labeling scheme is going to
>>>>> require network specific information, right?
>>>>>           
>>>> Right.  Refpolicy already can create a set of iptables rules based on
>>>> the ports defined in the policy, but its not currently shipped (which
>>>> was decided at the summit).
>>>>
>>>>         
>>> I don't think that there are particularly good restrictions that we can
>>> do out of the box. I think that we should instead focus on making it
>>> fairly easy to do customization with some documentation / recipes that
>>> people can follow.
>>>       
>> I still think the set that refpolicy can generate is fine.  It provides
>> the default ports for services on all interfaces.  This is better than
>> almost unconfined as it is now.  The incoming connections rules mirror
>> the name_bind rules, and the outgoing connections mirrors the
>> name_connect rules.  Since UDP doesn't have a connect we can cover that
>> reasonably too.  Then we get the connection tracking on all these too.
>>
>>     
>
> The problem is moving from this default to a customized version. How
> will a packet type be redefined? Additive rules are fine, but changing
> or removing rules is problematic.
>
> Anyway - I thought that this decision was already made. Are people
> wanting to discuss this again?
>
>   
>>> To that end, Chris / Dan, can you comment on my policy example? What I
>>> posted doesn't exactly work now and I would like to know what the
>>> suggested method for allowing almost all network facing daemons to
>>> receive unlabeled_t packets is going to be.
>>>       
>> Actually, my current idea is to make a tunable for each domain that
>> networks.  If we were to go the negation route, it would be something
>> like this in corenetwork:
>>
>> corenet_sendrecv_unlabeled_packets({ networking_domain -confined_networking_domain })
>>
>> Then corenetwork would provide interfaces to gain these attributes.
>>     
>
> Is this actively being worked on?
>
> Karl
>
>   

The other problem here is that it is not so clear what it means to be a 
networking domain.

Any application that does dns is a networking domain?  Any app that 
resolves a uid?



--
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: secmark integration

[Karl MacMillan]

On Wed, 2007-04-04 at 16:51 -0400, Daniel J Walsh wrote:
> Karl MacMillan wrote:
> > On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
> >   
> >> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> >>     
> >>> On Mon, 2007-04-02 at 15:15 +0000, Christopher J. PeBenito wrote:
> >>>       
> >>>> On Mon, 2007-04-02 at 10:55 -0400, Eric Paris wrote:
> >>>>         
> >>>>> Good idea.  Can anyone help me come up with any way in which we can use
> >>>>> secmark 'by default' and gain any greater protections than we already
> >>>>> have with name_{bind,connect}
> >>>>>
> >>>>> Seems to me that port number is the only thing we can label based on for
> >>>>> everyone out of the box.  Any more complex labeling scheme is going to
> >>>>> require network specific information, right?
> >>>>>           
> >>>> Right.  Refpolicy already can create a set of iptables rules based on
> >>>> the ports defined in the policy, but its not currently shipped (which
> >>>> was decided at the summit).
> >>>>
> >>>>         
> >>> I don't think that there are particularly good restrictions that we can
> >>> do out of the box. I think that we should instead focus on making it
> >>> fairly easy to do customization with some documentation / recipes that
> >>> people can follow.
> >>>       
> >> I still think the set that refpolicy can generate is fine.  It provides
> >> the default ports for services on all interfaces.  This is better than
> >> almost unconfined as it is now.  The incoming connections rules mirror
> >> the name_bind rules, and the outgoing connections mirrors the
> >> name_connect rules.  Since UDP doesn't have a connect we can cover that
> >> reasonably too.  Then we get the connection tracking on all these too.
> >>
> >>     
> >
> > The problem is moving from this default to a customized version. How
> > will a packet type be redefined? Additive rules are fine, but changing
> > or removing rules is problematic.
> >
> > Anyway - I thought that this decision was already made. Are people
> > wanting to discuss this again?
> >
> >   
> >>> To that end, Chris / Dan, can you comment on my policy example? What I
> >>> posted doesn't exactly work now and I would like to know what the
> >>> suggested method for allowing almost all network facing daemons to
> >>> receive unlabeled_t packets is going to be.
> >>>       
> >> Actually, my current idea is to make a tunable for each domain that
> >> networks.  If we were to go the negation route, it would be something
> >> like this in corenetwork:
> >>
> >> corenet_sendrecv_unlabeled_packets({ networking_domain -confined_networking_domain })
> >>
> >> Then corenetwork would provide interfaces to gain these attributes.
> >>     
> >
> > Is this actively being worked on?
> >
> > Karl
> >
> >   
> 
> The other problem here is that it is not so clear what it means to be a 
> networking domain.
> 

Yep.

> Any application that does dns is a networking domain?  Any app that 
> resolves a uid?
> 

I think it is going to have to be all of these - basically any app that,
by default, can receive unlabeled packets. BTW, we are going to need the
interface that grants access to unlabeled packets but has a boolean and
an interface that unconditionally allows that access (for use during
customizations).

Karl


--
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: secmark integration

[Christopher J. PeBenito]

On Thu, 2007-04-05 at 11:48 -0400, Karl MacMillan wrote:
> On Wed, 2007-04-04 at 16:51 -0400, Daniel J Walsh wrote:
> > Karl MacMillan wrote:
> > > On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
> > >> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> > >>> I don't think that there are particularly good restrictions that we can
> > >>> do out of the box. I think that we should instead focus on making it
> > >>> fairly easy to do customization with some documentation / recipes that
> > >>> people can follow.
> > >>>       
> > >> I still think the set that refpolicy can generate is fine.  It provides
> > >> the default ports for services on all interfaces.  This is better than
> > >> almost unconfined as it is now.  The incoming connections rules mirror
> > >> the name_bind rules, and the outgoing connections mirrors the
> > >> name_connect rules.  Since UDP doesn't have a connect we can cover that
> > >> reasonably too.  Then we get the connection tracking on all these too.
> > >
> > > The problem is moving from this default to a customized version. How
> > > will a packet type be redefined? Additive rules are fine, but changing
> > > or removing rules is problematic.

These are two separate issues.  My argument was about the quality of the
default rules, not about how well they could be managed.

> > >>> To that end, Chris / Dan, can you comment on my policy example? What I
> > >>> posted doesn't exactly work now and I would like to know what the
> > >>> suggested method for allowing almost all network facing daemons to
> > >>> receive unlabeled_t packets is going to be.
> > >>>       
> > >> Actually, my current idea is to make a tunable for each domain that
> > >> networks.  If we were to go the negation route, it would be something
> > >> like this in corenetwork:
> > >>
> > >> corenet_sendrecv_unlabeled_packets({ networking_domain -confined_networking_domain })
> > >>
> > >> Then corenetwork would provide interfaces to gain these attributes.
> > >>     
> > >
> > > Is this actively being worked on?
> > >
> > > Karl
> > >
> > >   
> > 
> > The other problem here is that it is not so clear what it means to be a 
> > networking domain.
> > 
> 
> Yep.
> 
> > Any application that does dns is a networking domain?  Any app that 
> > resolves a uid?
> > 
> 
> I think it is going to have to be all of these - basically any app that,
> by default, can receive unlabeled packets. BTW, we are going to need the
> interface that grants access to unlabeled packets but has a boolean and
> an interface that unconditionally allows that access (for use during
> customizations).

No, two interfaces aren't going to be needed.  If you go the negation
route, then users will be putting the interface call that gets the
confined_networking_domain attribute in their local.te when they want to
confine it.  If you go with my original idea, then the tunable will be
in the module itself.  The closest thing I can think of to what you're
saying would be to make a template that declares a tunable and then
encases a call to corenet_sendrecv_unlabeled_packets() inside of it,
which would be useful for my idea.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secmark integration

[Karl MacMillan]

On Thu, 2007-04-05 at 13:06 -0400, Christopher J. PeBenito wrote:
> On Thu, 2007-04-05 at 11:48 -0400, Karl MacMillan wrote:
> > On Wed, 2007-04-04 at 16:51 -0400, Daniel J Walsh wrote:
> > > Karl MacMillan wrote:
> > > > On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
> > > >> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> > > >>> I don't think that there are particularly good restrictions that we can
> > > >>> do out of the box. I think that we should instead focus on making it
> > > >>> fairly easy to do customization with some documentation / recipes that
> > > >>> people can follow.
> > > >>>       
> > > >> I still think the set that refpolicy can generate is fine.  It provides
> > > >> the default ports for services on all interfaces.  This is better than
> > > >> almost unconfined as it is now.  The incoming connections rules mirror
> > > >> the name_bind rules, and the outgoing connections mirrors the
> > > >> name_connect rules.  Since UDP doesn't have a connect we can cover that
> > > >> reasonably too.  Then we get the connection tracking on all these too.
> > > >
> > > > The problem is moving from this default to a customized version. How
> > > > will a packet type be redefined? Additive rules are fine, but changing
> > > > or removing rules is problematic.
> 
> These are two separate issues.  My argument was about the quality of the
> default rules, not about how well they could be managed.
> 

Ok - but you still seem to be suggesting generating defaults from
reference policy, which is what I think is basically unworkable.

As for the defaults themselves - there seems to be a decent chance that
adding restrictions will cause breakage. I'm ok with that as long as
there is a clear mechanism for users to relax the restrictions or go
back to the same restrictions that we have today (i.e., just name_bind
and name_connect).

That's why I keep talking about these issues together - our ability to
have tighter defaults depends, I think, on our ability to manage the
rules.

> > 
> > I think it is going to have to be all of these - basically any app that,
> > by default, can receive unlabeled packets. BTW, we are going to need the
> > interface that grants access to unlabeled packets but has a boolean and
> > an interface that unconditionally allows that access (for use during
> > customizations).
> 
> No, two interfaces aren't going to be needed.  If you go the negation
> route, then users will be putting the interface call that gets the
> confined_networking_domain attribute in their local.te when they want to
> confine it.  If you go with my original idea, then the tunable will be
> in the module itself.  The closest thing I can think of to what you're
> saying would be to make a template that declares a tunable and then
> encases a call to corenet_sendrecv_unlabeled_packets() inside of it,
> which would be useful for my idea.
> 

That sounds fine to me (assuming I understand), but I thought people
were concerned about the number of booleans.

Karl


--
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: secmark integration

[Stephen Smalley]

On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> On Thu, 2007-04-05 at 13:06 -0400, Christopher J. PeBenito wrote:
> > On Thu, 2007-04-05 at 11:48 -0400, Karl MacMillan wrote:
> > > On Wed, 2007-04-04 at 16:51 -0400, Daniel J Walsh wrote:
> > > > Karl MacMillan wrote:
> > > > > On Wed, 2007-04-04 at 17:22 +0000, Christopher J. PeBenito wrote:
> > > > >> On Mon, 2007-04-02 at 13:15 -0400, Karl MacMillan wrote:
> > > > >>> I don't think that there are particularly good restrictions that we can
> > > > >>> do out of the box. I think that we should instead focus on making it
> > > > >>> fairly easy to do customization with some documentation / recipes that
> > > > >>> people can follow.
> > > > >>>       
> > > > >> I still think the set that refpolicy can generate is fine.  It provides
> > > > >> the default ports for services on all interfaces.  This is better than
> > > > >> almost unconfined as it is now.  The incoming connections rules mirror
> > > > >> the name_bind rules, and the outgoing connections mirrors the
> > > > >> name_connect rules.  Since UDP doesn't have a connect we can cover that
> > > > >> reasonably too.  Then we get the connection tracking on all these too.
> > > > >
> > > > > The problem is moving from this default to a customized version. How
> > > > > will a packet type be redefined? Additive rules are fine, but changing
> > > > > or removing rules is problematic.
> > 
> > These are two separate issues.  My argument was about the quality of the
> > default rules, not about how well they could be managed.
> > 
> 
> Ok - but you still seem to be suggesting generating defaults from
> reference policy, which is what I think is basically unworkable.
> 
> As for the defaults themselves - there seems to be a decent chance that
> adding restrictions will cause breakage. I'm ok with that as long as
> there is a clear mechanism for users to relax the restrictions or go
> back to the same restrictions that we have today (i.e., just name_bind
> and name_connect).
> 
> That's why I keep talking about these issues together - our ability to
> have tighter defaults depends, I think, on our ability to manage the
> rules.
> 
> > > 
> > > I think it is going to have to be all of these - basically any app that,
> > > by default, can receive unlabeled packets. BTW, we are going to need the
> > > interface that grants access to unlabeled packets but has a boolean and
> > > an interface that unconditionally allows that access (for use during
> > > customizations).
> > 
> > No, two interfaces aren't going to be needed.  If you go the negation
> > route, then users will be putting the interface call that gets the
> > confined_networking_domain attribute in their local.te when they want to
> > confine it.  If you go with my original idea, then the tunable will be
> > in the module itself.  The closest thing I can think of to what you're
> > saying would be to make a template that declares a tunable and then
> > encases a call to corenet_sendrecv_unlabeled_packets() inside of it,
> > which would be useful for my idea.
> > 
> 
> That sounds fine to me (assuming I understand), but I thought people
> were concerned about the number of booleans.

We just need a per-domain subtree of booleans under /selinux/booleans ;)
/selinux/booleans/httpd_t/enable_cgi 

Speaking of which, we do want to try to go with a one file per value
approach in selinuxfs, so on the dynamic class/perm discovery work,
let's try to provide a nice directory tree form of it.

-- 
Stephen Smalley
National Security Agency


--
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: secmark integration

[Stephen Smalley]

On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
> On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
> > On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> > > That sounds fine to me (assuming I understand), but I thought people
> > > were concerned about the number of booleans.
> > 
> > We just need a per-domain subtree of booleans under /selinux/booleans ;)
> > /selinux/booleans/httpd_t/enable_cgi 
> > 
> > Speaking of which, we do want to try to go with a one file per value
> > approach in selinuxfs, so on the dynamic class/perm discovery work,
> > let's try to provide a nice directory tree form of it.
> 
> Ok, that means I get to start over. :)  I was doing some final debugging
> on a single /selinux/class node that uses a simple transaction
> like /selinux/access.
> 
> Just to be certain, you're asking for
> 
> /selinux/class/[classname]/index
> /selinux/class/[classname]/[permname]
> 
> where each of those just return the values?

Yes, doesn't that sound nicer?

-- 
Stephen Smalley
National Security Agency


--
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: secmark integration

[Christopher J. PeBenito]

On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
> On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> > That sounds fine to me (assuming I understand), but I thought people
> > were concerned about the number of booleans.
> 
> We just need a per-domain subtree of booleans under /selinux/booleans ;)
> /selinux/booleans/httpd_t/enable_cgi 
> 
> Speaking of which, we do want to try to go with a one file per value
> approach in selinuxfs, so on the dynamic class/perm discovery work,
> let's try to provide a nice directory tree form of it.

Ok, that means I get to start over. :)  I was doing some final debugging
on a single /selinux/class node that uses a simple transaction
like /selinux/access.

Just to be certain, you're asking for

/selinux/class/[classname]/index
/selinux/class/[classname]/[permname]

where each of those just return the values?

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secmark integration

[Christopher J. PeBenito]

On Thu, 2007-04-05 at 13:59 -0400, Stephen Smalley wrote:
> On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
> > On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
> > > On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> > > > That sounds fine to me (assuming I understand), but I thought people
> > > > were concerned about the number of booleans.
> > > 
> > > We just need a per-domain subtree of booleans under /selinux/booleans ;)
> > > /selinux/booleans/httpd_t/enable_cgi 
> > > 
> > > Speaking of which, we do want to try to go with a one file per value
> > > approach in selinuxfs, so on the dynamic class/perm discovery work,
> > > let's try to provide a nice directory tree form of it.
> > 
> > Ok, that means I get to start over. :)  I was doing some final debugging
> > on a single /selinux/class node that uses a simple transaction
> > like /selinux/access.
> > 
> > Just to be certain, you're asking for
> > 
> > /selinux/class/[classname]/index
> > /selinux/class/[classname]/[permname]
> > 
> > where each of those just return the values?
> 
> Yes, doesn't that sound nicer?

Its fine with me, though it was just mentioned to me that we'll have
problems if there is a future perm named index.  Suggestions on what to
call that node?

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: secmark integration

[Joshua Brindle]

Christopher J. PeBenito wrote:
> On Thu, 2007-04-05 at 13:59 -0400, Stephen Smalley wrote:
>   
>> On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
>>     
>>> On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
>>>       
>>>> On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
>>>>         
>>>>> That sounds fine to me (assuming I understand), but I thought people
>>>>> were concerned about the number of booleans.
>>>>>           
>>>> We just need a per-domain subtree of booleans under /selinux/booleans ;)
>>>> /selinux/booleans/httpd_t/enable_cgi 
>>>>
>>>> Speaking of which, we do want to try to go with a one file per value
>>>> approach in selinuxfs, so on the dynamic class/perm discovery work,
>>>> let's try to provide a nice directory tree form of it.
>>>>         
>>> Ok, that means I get to start over. :)  I was doing some final debugging
>>> on a single /selinux/class node that uses a simple transaction
>>> like /selinux/access.
>>>
>>> Just to be certain, you're asking for
>>>
>>> /selinux/class/[classname]/index
>>> /selinux/class/[classname]/[permname]
>>>
>>> where each of those just return the values?
>>>       
>> Yes, doesn't that sound nicer?
>>     
>
> Its fine with me, though it was just mentioned to me that we'll have
> problems if there is a future perm named index.  Suggestions on what to
> call that node?
>   
How about ...security? :)

It sucks to reserve something in every permission namespace for this 
usage, __val__ or something maybe?

--
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: secmark integration

[Stephen Smalley]

On Thu, 2007-04-05 at 13:59 -0400, Stephen Smalley wrote:
> On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
> > On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
> > > On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> > > > That sounds fine to me (assuming I understand), but I thought people
> > > > were concerned about the number of booleans.
> > > 
> > > We just need a per-domain subtree of booleans under /selinux/booleans ;)
> > > /selinux/booleans/httpd_t/enable_cgi 
> > > 
> > > Speaking of which, we do want to try to go with a one file per value
> > > approach in selinuxfs, so on the dynamic class/perm discovery work,
> > > let's try to provide a nice directory tree form of it.
> > 
> > Ok, that means I get to start over. :)  I was doing some final debugging
> > on a single /selinux/class node that uses a simple transaction
> > like /selinux/access.
> > 
> > Just to be certain, you're asking for
> > 
> > /selinux/class/[classname]/index
> > /selinux/class/[classname]/[permname]
> > 
> > where each of those just return the values?
> 
> Yes, doesn't that sound nicer?

The transaction ops make sense when we are computing a policy decision
based on variable inputs, but for the class/perm info, it is just
exporting fixed state about the policy (only changing when the policy is
reloaded).

-- 
Stephen Smalley
National Security Agency


--
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: secmark integration

[Stephen Smalley]

On Thu, 2007-04-05 at 14:46 -0400, Christopher J. PeBenito wrote:
> On Thu, 2007-04-05 at 13:59 -0400, Stephen Smalley wrote:
> > On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
> > > On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
> > > > On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> > > > > That sounds fine to me (assuming I understand), but I thought people
> > > > > were concerned about the number of booleans.
> > > > 
> > > > We just need a per-domain subtree of booleans under /selinux/booleans ;)
> > > > /selinux/booleans/httpd_t/enable_cgi 
> > > > 
> > > > Speaking of which, we do want to try to go with a one file per value
> > > > approach in selinuxfs, so on the dynamic class/perm discovery work,
> > > > let's try to provide a nice directory tree form of it.
> > > 
> > > Ok, that means I get to start over. :)  I was doing some final debugging
> > > on a single /selinux/class node that uses a simple transaction
> > > like /selinux/access.
> > > 
> > > Just to be certain, you're asking for
> > > 
> > > /selinux/class/[classname]/index
> > > /selinux/class/[classname]/[permname]
> > > 
> > > where each of those just return the values?
> > 
> > Yes, doesn't that sound nicer?
> 
> Its fine with me, though it was just mentioned to me that we'll have
> problems if there is a future perm named index.  Suggestions on what to
> call that node?

00index ;)

-- 
Stephen Smalley
National Security Agency


--
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: secmark integration

[Eamon Walsh]

Stephen Smalley wrote:
> On Thu, 2007-04-05 at 14:46 -0400, Christopher J. PeBenito wrote:
>> On Thu, 2007-04-05 at 13:59 -0400, Stephen Smalley wrote:
>>> On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
>>>> On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
>>>>> On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
>>>>>> That sounds fine to me (assuming I understand), but I thought people
>>>>>> were concerned about the number of booleans.
>>>>> We just need a per-domain subtree of booleans under /selinux/booleans ;)
>>>>> /selinux/booleans/httpd_t/enable_cgi 
>>>>>
>>>>> Speaking of which, we do want to try to go with a one file per value
>>>>> approach in selinuxfs, so on the dynamic class/perm discovery work,
>>>>> let's try to provide a nice directory tree form of it.
>>>> Ok, that means I get to start over. :)  I was doing some final debugging
>>>> on a single /selinux/class node that uses a simple transaction
>>>> like /selinux/access.
>>>>
>>>> Just to be certain, you're asking for
>>>>
>>>> /selinux/class/[classname]/index
>>>> /selinux/class/[classname]/[permname]
>>>>
>>>> where each of those just return the values?
>>> Yes, doesn't that sound nicer?
>> Its fine with me, though it was just mentioned to me that we'll have
>> problems if there is a future perm named index.  Suggestions on what to
>> call that node?
> 
> 00index ;)
> 

Directories are cheap:

/selinux/class/[classname]/index
/selinux/class/[classname]/perms/[permname]



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
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: secmark integration

[Stephen Smalley]

On Thu, 2007-04-05 at 15:53 -0400, Eamon Walsh wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-04-05 at 14:46 -0400, Christopher J. PeBenito wrote:
> >> On Thu, 2007-04-05 at 13:59 -0400, Stephen Smalley wrote:
> >>> On Thu, 2007-04-05 at 14:02 -0400, Christopher J. PeBenito wrote:
> >>>> On Thu, 2007-04-05 at 13:47 -0400, Stephen Smalley wrote:
> >>>>> On Thu, 2007-04-05 at 13:40 -0400, Karl MacMillan wrote:
> >>>>>> That sounds fine to me (assuming I understand), but I thought people
> >>>>>> were concerned about the number of booleans.
> >>>>> We just need a per-domain subtree of booleans under /selinux/booleans ;)
> >>>>> /selinux/booleans/httpd_t/enable_cgi 
> >>>>>
> >>>>> Speaking of which, we do want to try to go with a one file per value
> >>>>> approach in selinuxfs, so on the dynamic class/perm discovery work,
> >>>>> let's try to provide a nice directory tree form of it.
> >>>> Ok, that means I get to start over. :)  I was doing some final debugging
> >>>> on a single /selinux/class node that uses a simple transaction
> >>>> like /selinux/access.
> >>>>
> >>>> Just to be certain, you're asking for
> >>>>
> >>>> /selinux/class/[classname]/index
> >>>> /selinux/class/[classname]/[permname]
> >>>>
> >>>> where each of those just return the values?
> >>> Yes, doesn't that sound nicer?
> >> Its fine with me, though it was just mentioned to me that we'll have
> >> problems if there is a future perm named index.  Suggestions on what to
> >> call that node?
> > 
> > 00index ;)
> > 
> 
> Directories are cheap:
> 
> /selinux/class/[classname]/index
> /selinux/class/[classname]/perms/[permname]

Yes, that's a better idea.

-- 
Stephen Smalley
National Security Agency


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