public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "Ahmed S. Darwish" <darwish.07@gmail.com>,
	Casey Schaufler <casey@schaufler-ca.com>
Cc: torvalds@osdl.org, akpm@osdl.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
Date: Sun, 14 Oct 2007 20:30:53 -0700 (PDT)	[thread overview]
Message-ID: <779660.41682.qm@web36610.mail.mud.yahoo.com> (raw)
In-Reply-To: <20071014231358.GA5565@Ahmed>


--- "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:

> Hi Casey,
> 
> On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
> > 
> > +
> > +CIPSO Configuration
> > +
> > +It is normally unnecessary to specify the CIPSO configuration. The default
> > +values used by the system handle all internal cases. Smack will compose
> CIPSO
> > +label values to match the Smack labels being used without administrative
> > +intervention. 
> >
> 
> I have two issues with CIPSO and Smack:
> 
> 1-
> 
> Using default configuration (system startup script + smacfs fstab line),
> system
> can't access any service outside the Lan. "ICMP parameter problem message"
> always
> appear from the first Wan router (traceroute + tcpdump at [1]).
> 
> Services inside the LAN can be accessed normally. System can connect to a Lan
> Windows share. It also connects to the gateway HTTP server easily.
> 
> After some tweaking, I discovered that using CIPSOv6 solves all above
> problems:
> $ echo -n "NLBL_CIPSOv6" > /smack/nltype
> 
> Is this a normal behaviour ?

Well ... sort of. CIPSOv6 isn't actually implemented in the
labeled networking code. What you're seeing is unlabeled packets.

As far as CIPSOv4 and your WAN router, It is possible that it is
configured either to reject CIPSO packets or to allow only CIPSO
packets in a particular DOI or to enforce a CIPSO policy of its
own.

> 2-
> 
> > 4. Any access requested on an object labeled "*" is permitted.
> [...]
> > +Unlabeled packets that come into the system will be given the
> > +ambient label.
> 
> Default conf let the ambient attribute = _ which works fine. Setting ambient
> = *
> stops all external (non lo) network traffic. Did I miss another use of
> "ambient"
> or this is a normal behaviour ?.

An IP operation is considered a write from the sender to the receiver.
The packet label is the label of the sender. Thus, in the unlabeled
packet case, the ambient label ("*" in your case) is attached to packet,
and the access check always denies access because of the first access
rule, which is that a subject with a star label will always be denied
access.

> > +Administration
> > +
> > +Smack supports some mount options:
> > +
> > +	smackfsdef=label: specifies the label to give files that lack
> > +	the Smack label extended attribute.
> > +
> 
> Although using smackfsdef=* as a mount option, all my system files have the
> floor
> attribute. Most of the /dev files have the * attribute though.

The smackfsdef mount option applies to files that don't actually
have the security.SMACK64 attribute. If those files have the attribute
whatever value is associated with it will be used.


Thank you.


Casey Schaufler
casey@schaufler-ca.com

  reply	other threads:[~2007-10-15  3:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-14 17:15 [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-10-14 17:34 ` Al Viro
2007-10-14 17:56   ` Casey Schaufler
2007-10-14 23:13 ` Ahmed S. Darwish
2007-10-15  3:30   ` Casey Schaufler [this message]
2007-10-15 15:12     ` Paul Moore

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=779660.41682.qm@web36610.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=akpm@osdl.org \
    --cc=darwish.07@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox