Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Sunday 14 October 2007 11:30:53 pm Casey Schaufler wrote: > --- "Ahmed S. Darwish" <[EMAIL PROTECTED]> 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. The how/why of the packet rejection probably isn't all that important, but the most likely scenario based on the ICMP error code is that the router simply does not know about the CIPSO IP option type and is dropping the packet as a result. I'd be very surprised to see a standard router in general use which has policy to perform packet level access control using CIPSO options/labels. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Sunday 14 October 2007 11:30:53 pm Casey Schaufler wrote: --- Ahmed S. Darwish [EMAIL PROTECTED] 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. The how/why of the packet rejection probably isn't all that important, but the most likely scenario based on the ICMP error code is that the router simply does not know about the CIPSO IP option type and is dropping the packet as a result. I'd be very surprised to see a standard router in general use which has policy to perform packet level access control using CIPSO options/labels. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
--- "Ahmed S. Darwish" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
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 ? 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 ?. > +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. [1] traceroute to google.com (64.233.187.99), 30 hops max, 40 byte packets 1 host-196.218.207.17.tedata.net (196.218.207.17) 1.976 ms 1.850 ms 2.127 ms 2 DOKKI-R03C-GZ-EG (163.121.170.78) 27.429 ms 28.091 ms 23.336 ms Here's the tcpdump for accessing google.com: 22:51:26.008883 IP host-196.218.207.18.tedata.net.54011 > host-196.218.207.17.tedata.net.domain: 11001+ A? google.com. (28) 22:51:26.011066 IP host-196.218.207.18.tedata.net.45317 > host-196.218.207.17.tedata.net.domain: 44913+[|domain] 22:51:26.052154 IP host-196.218.207.17.tedata.net.domain > host-196.218.207.18.tedata.net.54011: 11001 3/0/0 A py-in-f99.google.com,[|domain] 22:51:26.052700 IP host-196.218.207.18.tedata.net.57180 > py-in-f99.google.com.www: S 282373541:282373541(0) win 5840 22:51:26.090608 IP host-196.218.207.17.tedata.net.domain > host-196.218.207.18.tedata.net.45317: 44913 1/0/0 (89) 22:51:26.091473 IP host-196.218.207.18.tedata.net.34417 > host-196.218.207.17.tedata.net.domain: 49202+[|domain] --> 22:51:26.105443 IP DOKKI-R03C-GZ-EG > host-196.218.207.18.tedata.net: ICMP parameter problem - octet 20, length 48 Best Regards, -- Ahmed S. Darwish HomePage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
> > This version fixes a major blunder in label handling. The system
> > works, but has a serious memory leak that also induces a gradual
> > performance degradation. Al Viro gets the credit for pointing out
> > that one. Al suggested several other improvements that are not
> > included. They should come soon, but I wanted to get this flaw
> > out of the code before too many people hit it.
>
> Ahem... This
>
> > +static ssize_t smk_write_doi(struct file *file, const char __user *buf,
> > +size_t count, loff_t *ppos)
> > +{
> > + char temp[80];
> > + int i;
> > +
> > + if (!capable(CAP_MAC_OVERRIDE))
> > + return -EPERM;
> > +
> > + if (count > sizeof(temp))
> > + return -EINVAL;
> > +
> > + if (copy_from_user(temp, buf, count) != 0)
> > + return -EFAULT;
> > +
> > + if (sscanf(temp, "%d", ) != 1)
> > + return -EINVAL;
>
> is not really a missing improvement; it's a geniune undefined behaviour.
> temp[] is uninitialized, then you copy there some data that doesn't have
> to contain NUL, then you call sscanf(). Boom. The same goes for the rest
> of similar places.
>
> And this
>
> > +static ssize_t smk_read_ambient(struct file *filp, char __user *buf,
> > + size_t cn, loff_t *ppos)
> > +{
> > + ssize_t rc;
> > + int asize = strlen(smack_net_ambient) + 1;
> > +
> > + if (cn < asize)
> > + return -EINVAL;
> > +
> > + if (*ppos != 0)
> > + return 0;
> > +
> > + rc = simple_read_from_buffer(buf, cn, ppos, smack_net_ambient, asize);
>
> is honest-to-$DEITY security hole - that file is world-readable and there's
> nothing to prevent simple_read_from_buffer() blocking on page-in of buf,
> then root writing to that file changing smack_net_ambient and doing kfree()
> on the old value - one we'd already passed to simple_read_from_buffer().
> At which point reader is about to get whatever data that might land in
> whatever that memory gets reused for.
>
> Besides, as I said the last time, smack_net_ambient has every right to
> get changed between strlen() and passing argument to
> simple_read_from_buffer(),
> in which case you'll be copying the amount of data that used to be in the
> old one, taking it from the new one. New one might very well be shorter.
Yep. I got work to do. I know it ain't getting done today, and I know
that the change I put out is affecting people, so I decided not to
wait until I'd done the whole lot.
Sorry if it sounded as if I wasn't taking the comments seriously.
I am. Thank you again.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
> This version fixes a major blunder in label handling. The system
> works, but has a serious memory leak that also induces a gradual
> performance degradation. Al Viro gets the credit for pointing out
> that one. Al suggested several other improvements that are not
> included. They should come soon, but I wanted to get this flaw
> out of the code before too many people hit it.
Ahem... This
> +static ssize_t smk_write_doi(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + char temp[80];
> + int i;
> +
> + if (!capable(CAP_MAC_OVERRIDE))
> + return -EPERM;
> +
> + if (count > sizeof(temp))
> + return -EINVAL;
> +
> + if (copy_from_user(temp, buf, count) != 0)
> + return -EFAULT;
> +
> + if (sscanf(temp, "%d", ) != 1)
> + return -EINVAL;
is not really a missing improvement; it's a geniune undefined behaviour.
temp[] is uninitialized, then you copy there some data that doesn't have
to contain NUL, then you call sscanf(). Boom. The same goes for the rest
of similar places.
And this
> +static ssize_t smk_read_ambient(struct file *filp, char __user *buf,
> + size_t cn, loff_t *ppos)
> +{
> + ssize_t rc;
> + int asize = strlen(smack_net_ambient) + 1;
> +
> + if (cn < asize)
> + return -EINVAL;
> +
> + if (*ppos != 0)
> + return 0;
> +
> + rc = simple_read_from_buffer(buf, cn, ppos, smack_net_ambient, asize);
is honest-to-$DEITY security hole - that file is world-readable and there's
nothing to prevent simple_read_from_buffer() blocking on page-in of buf,
then root writing to that file changing smack_net_ambient and doing kfree()
on the old value - one we'd already passed to simple_read_from_buffer().
At which point reader is about to get whatever data that might land in
whatever that memory gets reused for.
Besides, as I said the last time, smack_net_ambient has every right to
get changed between strlen() and passing argument to simple_read_from_buffer(),
in which case you'll be copying the amount of data that used to be in the
old one, taking it from the new one. New one might very well be shorter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
This version fixes a major blunder in label handling. The system
works, but has a serious memory leak that also induces a gradual
performance degradation. Al Viro gets the credit for pointing out
that one. Al suggested several other improvements that are not
included. They should come soon, but I wanted to get this flaw
out of the code before too many people hit it.
Ahem... This
+static ssize_t smk_write_doi(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ char temp[80];
+ int i;
+
+ if (!capable(CAP_MAC_OVERRIDE))
+ return -EPERM;
+
+ if (count sizeof(temp))
+ return -EINVAL;
+
+ if (copy_from_user(temp, buf, count) != 0)
+ return -EFAULT;
+
+ if (sscanf(temp, %d, i) != 1)
+ return -EINVAL;
is not really a missing improvement; it's a geniune undefined behaviour.
temp[] is uninitialized, then you copy there some data that doesn't have
to contain NUL, then you call sscanf(). Boom. The same goes for the rest
of similar places.
And this
+static ssize_t smk_read_ambient(struct file *filp, char __user *buf,
+ size_t cn, loff_t *ppos)
+{
+ ssize_t rc;
+ int asize = strlen(smack_net_ambient) + 1;
+
+ if (cn asize)
+ return -EINVAL;
+
+ if (*ppos != 0)
+ return 0;
+
+ rc = simple_read_from_buffer(buf, cn, ppos, smack_net_ambient, asize);
is honest-to-$DEITY security hole - that file is world-readable and there's
nothing to prevent simple_read_from_buffer() blocking on page-in of buf,
then root writing to that file changing smack_net_ambient and doing kfree()
on the old value - one we'd already passed to simple_read_from_buffer().
At which point reader is about to get whatever data that might land in
whatever that memory gets reused for.
Besides, as I said the last time, smack_net_ambient has every right to
get changed between strlen() and passing argument to simple_read_from_buffer(),
in which case you'll be copying the amount of data that used to be in the
old one, taking it from the new one. New one might very well be shorter.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote:
On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
This version fixes a major blunder in label handling. The system
works, but has a serious memory leak that also induces a gradual
performance degradation. Al Viro gets the credit for pointing out
that one. Al suggested several other improvements that are not
included. They should come soon, but I wanted to get this flaw
out of the code before too many people hit it.
Ahem... This
+static ssize_t smk_write_doi(struct file *file, const char __user *buf,
+size_t count, loff_t *ppos)
+{
+ char temp[80];
+ int i;
+
+ if (!capable(CAP_MAC_OVERRIDE))
+ return -EPERM;
+
+ if (count sizeof(temp))
+ return -EINVAL;
+
+ if (copy_from_user(temp, buf, count) != 0)
+ return -EFAULT;
+
+ if (sscanf(temp, %d, i) != 1)
+ return -EINVAL;
is not really a missing improvement; it's a geniune undefined behaviour.
temp[] is uninitialized, then you copy there some data that doesn't have
to contain NUL, then you call sscanf(). Boom. The same goes for the rest
of similar places.
And this
+static ssize_t smk_read_ambient(struct file *filp, char __user *buf,
+ size_t cn, loff_t *ppos)
+{
+ ssize_t rc;
+ int asize = strlen(smack_net_ambient) + 1;
+
+ if (cn asize)
+ return -EINVAL;
+
+ if (*ppos != 0)
+ return 0;
+
+ rc = simple_read_from_buffer(buf, cn, ppos, smack_net_ambient, asize);
is honest-to-$DEITY security hole - that file is world-readable and there's
nothing to prevent simple_read_from_buffer() blocking on page-in of buf,
then root writing to that file changing smack_net_ambient and doing kfree()
on the old value - one we'd already passed to simple_read_from_buffer().
At which point reader is about to get whatever data that might land in
whatever that memory gets reused for.
Besides, as I said the last time, smack_net_ambient has every right to
get changed between strlen() and passing argument to
simple_read_from_buffer(),
in which case you'll be copying the amount of data that used to be in the
old one, taking it from the new one. New one might very well be shorter.
Yep. I got work to do. I know it ain't getting done today, and I know
that the change I put out is affecting people, so I decided not to
wait until I'd done the whole lot.
Sorry if it sounded as if I wasn't taking the comments seriously.
I am. Thank you again.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
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 ? 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 ?. +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. [1] traceroute to google.com (64.233.187.99), 30 hops max, 40 byte packets 1 host-196.218.207.17.tedata.net (196.218.207.17) 1.976 ms 1.850 ms 2.127 ms 2 DOKKI-R03C-GZ-EG (163.121.170.78) 27.429 ms 28.091 ms 23.336 ms Here's the tcpdump for accessing google.com: 22:51:26.008883 IP host-196.218.207.18.tedata.net.54011 host-196.218.207.17.tedata.net.domain: 11001+ A? google.com. (28) 22:51:26.011066 IP host-196.218.207.18.tedata.net.45317 host-196.218.207.17.tedata.net.domain: 44913+[|domain] 22:51:26.052154 IP host-196.218.207.17.tedata.net.domain host-196.218.207.18.tedata.net.54011: 11001 3/0/0 A py-in-f99.google.com,[|domain] 22:51:26.052700 IP host-196.218.207.18.tedata.net.57180 py-in-f99.google.com.www: S 282373541:282373541(0) win 5840 mss 1460,sackOK,timestamp 741383 0,nop,wscale 5 22:51:26.090608 IP host-196.218.207.17.tedata.net.domain host-196.218.207.18.tedata.net.45317: 44913 1/0/0 (89) 22:51:26.091473 IP host-196.218.207.18.tedata.net.34417 host-196.218.207.17.tedata.net.domain: 49202+[|domain] -- 22:51:26.105443 IP DOKKI-R03C-GZ-EG host-196.218.207.18.tedata.net: ICMP parameter problem - octet 20, length 48 Best Regards, -- Ahmed S. Darwish HomePage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
--- Ahmed S. Darwish [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
