Shorewall devel - Sep 2010 - Shorewall 'policy' file question (secmark inclusion)

Is there a way I could specify the context of a ''default''
traffic not
already matched in my secmarks file in a similar fashion as to how the 
policy file operates in Shorewall with regards to whether it allows or 
disallows traffic?

The reason is simple - due to current (and in my view very big) 
shortcomings in the default SELinux policy once a ''default''
traffic
(i.e. traffic not owned by a particular SELinux context) is allowed it 
cannot be disallowed in any way, shape or form!

Most of the modules which make out the SELinux policy allow
''unlabelled''
traffic (that is traffic which does not have any security context 
attached to it) or traffic to/from ''unlabelled'' node or
interfaces (for
those interested there is more on this here - 
http://lists.fedoraproject.org/pipermail/selinux/2010-September/013044.html).

The only way I see in which I could stop that is to attach a
''dummy''
security context (say ''system_u:object_r_not_labelled_t:s0'')
to traffic
which is not defined/captured by the secmarks file - in a similar 
fashion how the policy file works in Shorewall.

Is that doable?


------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

On 09/23/2010 09:22 AM, Mr Dash Four wrote:
> Is there a way I could specify the context of a ''default''
traffic not
> already matched in my secmarks file in a similar fashion as to how the 
> policy file operates in Shorewall with regards to whether it allows or 
> disallows traffic?
> 
> The reason is simple - due to current (and in my view very big) 
> shortcomings in the default SELinux policy once a
''default'' traffic
> (i.e. traffic not owned by a particular SELinux context) is allowed it 
> cannot be disallowed in any way, shape or form!
> 
> Most of the modules which make out the SELinux policy allow
''unlabelled''
> traffic (that is traffic which does not have any security context 
> attached to it) or traffic to/from ''unlabelled'' node or
interfaces (for
> those interested there is more on this here - 
>
http://lists.fedoraproject.org/pipermail/selinux/2010-September/013044.html).
> 
> The only way I see in which I could stop that is to attach a
''dummy''
> security context (say
''system_u:object_r_not_labelled_t:s0'') to traffic
> which is not defined/captured by the secmarks file - in a similar 
> fashion how the policy file works in Shorewall.
> 
> Is that doable?
That doesn''t need Shorewall support -- just set that context first for
NEW
connections then override it for specific applications.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

> That doesn''t need Shorewall support -- just set that context first
for NEW
> connections then override it for specific applications.
>   
I was not sure is the matching mechanism in secmarks the same as in the 
rules file (i.e. first match wins)?

If that is so, then - you are right - I could include a capture-all rule 
for this ''dummy'' context right at the end, but this is also
true for the
policy and rules files as well - I could always include a capture-all 
ALLOW/DENY at the end of the rules file and that will, in effect, be the 
same as specifying exactly the same thing in policy file, wouldn''t it 
(in fact, I think I remember in the early Shorewall versions that used 
to be the case, right?)?

So, I guess what I am really after is something similar to the policy 
file, but for secmarks.


------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

On 9/23/10 9:50 AM, Mr Dash Four wrote:
> 
>> That doesn''t need Shorewall support -- just set that context
first for NEW
>> connections then override it for specific applications.
>>   
> I was not sure is the matching mechanism in secmarks the same as in the 
> rules file (i.e. first match wins)?
> 
> If that is so, then - you are right - I could include a capture-all rule 
> for this ''dummy'' context right at the end
No -- it must be at the beginning.
> but this is also true for the 
> policy and rules files as well - I could always include a capture-all 
> ALLOW/DENY at the end of the rules file and that will, in effect, be the 
> same as specifying exactly the same thing in policy file, wouldn''t
it
> (in fact, I think I remember in the early Shorewall versions that used 
> to be the case, right?)?
No -- Shorewall has always had a policy file. And The compiler complains
(warning) if you add a rule that is, in fact, a policy (e.g. ACTION,
SOURCE, and DEST and nothing else).
> 
> So, I guess what I am really after is something similar to the policy 
> file, but for secmarks.
Sorry -- I don''t believe that it is worth the effort.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

> No -- it must be at the beginning.
>   
In that case if I have a subsequent match(es) should I then assume the 
latest matching rule takes precedence?

If that is so this is different from the rules file where the first 
match wins - here is the opposite - the last match wins, is that right 
(in which case the broader rules should, indeed, be at the beginning)?
> No -- Shorewall has always had a policy file. And The compiler complains
> (warning) if you add a rule that is, in fact, a policy (e.g. ACTION,
> SOURCE, and DEST and nothing else).
>   
I thought wrong then.
>> So, I guess what I am really after is something similar to the policy 
>> file, but for secmarks.
>>     
>
> Sorry -- I don''t believe that it is worth the effort.
>   
Fair enough Tom.


------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

On 09/23/2010 10:56 AM, Mr Dash Four wrote:
> 
>> No -- it must be at the beginning.
>>   
> In that case if I have a subsequent match(es) should I then assume the 
> latest matching rule takes precedence?
SECMARK rules, like MARK rules, are non-terminating. So even when a rule
matches, the packet is passed on to the next rule.
> 
> If that is so this is different from the rules file where the first 
> match wins - here is the opposite - the last match wins, is that right 
> (in which case the broader rules should, indeed, be at the beginning)?
Yes -- same as in the tcrules file.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev