All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <jbrindle@tresys.com>
To: casey@schaufler-ca.com
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>,
	SELinux Mail List <selinux@tycho.nsa.gov>
Subject: Re: [PATCH 0/6] netfilter integration
Date: Mon, 17 Jul 2006 20:18:03 -0400	[thread overview]
Message-ID: <44BC28BB.1080701@tresys.com> (raw)
In-Reply-To: <20060717223444.4837.qmail@web36612.mail.mud.yahoo.com>

Casey Schaufler wrote:
> 
> --- "Christopher J. PeBenito" <cpebenito@tresys.com>
> wrote:
> 
>> This patchset adds support for netfilter secmark
>> rules in all policy
>> packages.  Each line of the file has a priority
>> (1-9) at the beginning
>> of the line, and the remainder is treated as the
>> rule.  Sorting is by
>> priority (1-9), and is stable within a module.  The
>> current design is
>> for the resultant netfilter_contexts file be
>> suitable for use with
>> iptables-restore.
> 
> How confident are you that 9 priorities
> will be sufficient? I can easily imaging
> dependency scenarios that would exceed
> this limitation. I would also expect that
> explict ordering within a priority is 
> going to be requested as soon as this
> goes into production.
> 
in reality probably 3 priorities would be sufficient. Specific port, 
port range and fallback. Its very doubtful that anything else would be 
necessary, especially in modules where the priority is much more 
important than in base. A module will very rarely have something more 
specific than ports, and since ports are non-overlapping it doesn't 
matter what order they are in (within a single priority)

> Speaking of dependencies, wouldn't a
> mechanism to declare dependencies a'la
> make be more precise? Just a thought.
> 
> 
eh? Policy modules already declare symbol dependencies explicitly (eg., 
which types, roles, etc this module uses)

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2006-07-18  0:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-17 20:32 [PATCH 0/6] netfilter integration Christopher J. PeBenito
2006-07-17 22:34 ` Casey Schaufler
2006-07-18  0:18   ` Joshua Brindle [this message]
2006-07-18  4:03     ` Casey Schaufler
2006-07-18 15:00     ` Karl MacMillan
2006-07-25 15:36       ` Christopher J. PeBenito
2006-07-25 19:02         ` Casey Schaufler
2006-07-26 14:23           ` Christopher J. PeBenito
2006-07-26 20:43             ` Karl MacMillan
2006-07-27 15:47             ` Casey Schaufler
2006-07-27 16:10               ` Karl MacMillan

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=44BC28BB.1080701@tresys.com \
    --to=jbrindle@tresys.com \
    --cc=casey@schaufler-ca.com \
    --cc=cpebenito@tresys.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

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

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