All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Piotr Sawicki <p.sawicki2@partner.samsung.com>,
	LSM <linux-security-module@vger.kernel.org>,
	"SMACK-discuss@lists.01.org" <SMACK-discuss@lists.01.org>
Cc: casey@schaufler-ca.com
Subject: Replacing IPv6 port labeling with CALIPSO in Smack
Date: Wed, 13 Mar 2019 15:55:36 -0700	[thread overview]
Message-ID: <2a019a5d-5024-d839-d72f-ffe5b554ef09@schaufler-ca.com> (raw)
In-Reply-To: <60d493f6-633f-e577-9947-cd41e1c762dc@schaufler-ca.com>

I am looking at CALIPSO support for Smack. CALIPSO provides
the same sort of network packet labeling for IPv6 that CIPSO
provides for IPv4. Because most of the details are buried in
the Netlabel code this should be reasonably straight forward.
The complication is that Smack has two mechanisms in place
for labeling IPv6 already, and neither uses anything like
CALIPSO packet labeling. If CONFIG_SECURITY_SMACK_NETFILTER
is defined Smack secids are sent via the netfilter secmark.
Otherwise, the Smack label of the process creating a socket
is maintained in a table indexed by the port number.

My proposed change would make the IPv6 labeling match the IPv4
labeling. The entire port number scheme would be abandoned.
The current secmark scheme would continue to be used if it
is configured. Whereas today IPv6 labeling is only supported
locally, the new code would support labeling remote systems as
well.

Systems that use CONFIG_SECURITY_SMACK_NETFILTER should be
unaffected for local use. The host address labeling scheme
would be retained, so any system configured to use IPv6
externally shouldn't see a difference. Systems that don't
use the option should also work the same as they do today.

Are there any users of Smack that use IPv6 but do not use
CONFIG_SECURITY_SMACK_NETFILTER? Does anyone have, know of
or imagine a use case where CALIPSO labeling would not be
a viable replacement for the hackish "port labeling"?

Thank you.


      reply	other threads:[~2019-03-13 22:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180719094732eucas1p18ac5bd15693cd06f868238c7a4951aa1@eucas1p1.samsung.com>
2018-07-19  9:47 ` [PATCH v3 RFC] Smack: Inform peer that IPv6 traffic has been blocked Piotr Sawicki
2018-07-19 22:51   ` Casey Schaufler
2018-07-23 20:04   ` Casey Schaufler
2019-03-13 22:55     ` Casey Schaufler [this message]

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=2a019a5d-5024-d839-d72f-ffe5b554ef09@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=SMACK-discuss@lists.01.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=p.sawicki2@partner.samsung.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.