lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 14 Oct 2007 20:30:53 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	"Ahmed S. Darwish" <darwish.07@...il.com>,
	Casey Schaufler <casey@...aufler-ca.com>
Cc:	torvalds@...l.org, akpm@...l.org,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel


--- "Ahmed S. Darwish" <darwish.07@...il.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@...aufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ