On Tuesday 29 January 2008 7:43:11 pm James Morris wrote:
> On Tue, 29 Jan 2008, Paul Moore wrote:
> > That seems reasonable. By the way, this isn't really related, but is it
> > possible to change the NF_IP_PRI_SELINUX_* constants to
> > NF_IP_PRI_SECURITY_* for the sake of consistency or are tho
On Tue, 29 Jan 2008, Paul Moore wrote:
> That seems reasonable. By the way, this isn't really related, but is it
> possible to change the NF_IP_PRI_SELINUX_* constants to NF_IP_PRI_SECURITY_*
> for the sake of consistency or are those values already visible to userspace?
>
They are visible
On Tuesday 29 January 2008 3:51:55 pm James Morris wrote:
> On Tue, 29 Jan 2008, Paul Moore wrote:
> > I'm not sure if returning false and failing here is the best thing to do
> > in terms of backwards compatibility. I think we need some grace period
> > where we print a warning message and still
On Tue, 29 Jan 2008, Paul Moore wrote:
> I'm not sure if returning false and failing here is the best thing to do in
> terms of backwards compatibility. I think we need some grace period where we
> print a warning message and still allow the operation; after some period of
> time we can then r
On Tuesday 29 January 2008 6:44:15 am James Morris wrote:
> The following patch implements a new "security" table for iptables, so
> that MAC (SELinux etc.) networking rules can be managed separately to
> standard DAC rules.
>
> This is to help with distro integration of the new secmark-based netwo
The following patch implements a new "security" table for iptables, so
that MAC (SELinux etc.) networking rules can be managed separately to
standard DAC rules.
This is to help with distro integration of the new secmark-based network
controls, per various previous discussions.
The need for a s
