From: Casey Schaufler <casey@schaufler-ca.com>
To: "Ahmed S. Darwish" <darwish.07@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Paul Moore <paul.moore@hp.com>
Cc: linux-security-module@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH BUGFIX -rc4] Smack: Respect 'unlabeled' netlabel mode
Date: Fri, 30 May 2008 16:10:37 -0700 (PDT) [thread overview]
Message-ID: <538684.41302.qm@web36603.mail.mud.yahoo.com> (raw)
In-Reply-To: <20080530233603.GA2994@ubuntu>
--- "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:
> Hi all,
>
> In case of Smack 'unlabeled' netlabel option, Smack passes a _zero_
> initialized 'secattr' to label a packet/sock. This causes an
> [unfound domain label error]/-ENOENT by netlbl_sock_setattr().
> Above Netlabel failure leads to Smack socket hooks failure causing
> an always-on socket() -EPERM error.
>
> Such packets should have a netlabel domain agreed with netlabel to
> represent unlabeled packets. Fortunately Smack net ambient label
> packets are agreed with netlabel to be treated as unlabeled packets.
>
> Treat all packets coming out from a 'unlabeled' Smack system as
> coming from the smack net ambient label.
To date the behavior of a Smack system running with nltype
unlabeled has been carefully undefined. The way you're defining
it will result in a system in which only processes running with
the ambient label will be able to use sockets, unless I'm reading
the code incorrectly. This seems like "correct" behavior, but
I don't think it is what those who've tried it would expect.
Casey Schaufler
casey@schaufler-ca.com
next prev parent reply other threads:[~2008-05-30 23:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-30 23:36 [PATCH BUGFIX -rc4] Smack: Respect 'unlabeled' netlabel mode Ahmed S. Darwish
2008-05-30 23:10 ` Casey Schaufler [this message]
2008-05-31 0:58 ` Ahmed S. Darwish
2008-05-31 0:37 ` Casey Schaufler
2008-05-31 13:08 ` Paul Moore
2008-05-30 23:57 ` [PATCH BUGFIX -v2 " Ahmed S. Darwish
2008-05-30 23:10 ` Tetsuo Handa
2008-05-30 23:25 ` Andrew Morton
2008-05-31 1:12 ` Ahmed S. Darwish
2008-05-30 23:45 ` Casey Schaufler
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=538684.41302.qm@web36603.mail.mud.yahoo.com \
--to=casey@schaufler-ca.com \
--cc=akpm@linux-foundation.org \
--cc=darwish.07@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.moore@hp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.