All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Tilman Baumann <tilman.baumann@collax.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org
Subject: Re: SMACK netfilter smacklabel socket match
Date: Mon, 06 Oct 2008 19:42:25 -0700	[thread overview]
Message-ID: <48EACC91.8040008@schaufler-ca.com> (raw)
In-Reply-To: <48EA0B30.6080907@collax.com>

Tilman Baumann wrote:
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>>> Casey Schaufler wrote:
>>> If I set /smack/nltype to 'unlabeled' I have effectively shut off 
>>> the network.
>>> I guess I'm missing some essential point here.
>>> Sorry to bother you with such trivialities.
>>
>> Not to worry. The essential point is that with MAC you can't just lock
>> the doors, you have to lock the windows as well. What I mean by that is
>> that traditional access controls apply to files, but not network
>> communications. Network communications became popular in part because
>> they were allowed to leave any restrictions up to the applications
>> and their protocols. MAC requirements are pickier than that. The good
>> news is that with a scheme like CIPSO you can easily enforce the
>> policy. The bad news is that network services in general assume that
>> there is no policy being enforced on them.
>
> This might work well in trusted networks.
> But Internet is untrusted and needs to work too. At least in the most 
> real world scenarios. :)

Yes. I'm pretty close to convinced that it needs to be included as
part of the single-label host solution. Not that it can possibly be
excused in any real secure environment mind you.

>>> If i set /smack/nltype to 'unlabled' i don't even get SYN packets 
>>> out. (operation not permitted)
>>
>> That's probably a bug, but I think the "fix" is to disable the 
>> ability to
>> set the nltype to anything other than CIPSO at least for the time being.
>
> Well, there is a case statement in smack_lsm.c that checks for the 
> nltype (smack_net_nltype) and omits net labeling if cipso is not set.
> This seems to be a very sensible thing to do. I strongly advice for a 
> way to omit netlabel based access control.

Yes, I hear you.

> As soon as you leave controlled and trusted networks, netlabels seem 
> in my eyes like a maybe even critical information leak.
>
> btw. I tried return 0; in smk_access(), but it did not make networking 
> work again with nltype set to unlabled. So I guess the problem is not 
> some access check.
>
> If you have any idea how i can avoid any cipso labels on the network 
> but use smack for local access control?
> I don't try to secure information channels. Our system is a general 
> purpose server, it would defeat the purpose of our system to lock it 
> up since our clients are never going to use cipso.
>
> I'm pretty sure the cipso labels are the problem. Since I can easily 
> access resources in the local network. But things break when I access 
> over Internet.
> And I can not even expect this to work in any network where the system 
> will be deployed.
>


  parent reply	other threads:[~2008-10-07  2:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-25 17:25 SMACK netfilter smacklabel socket match Tilman Baumann
2008-09-25 18:26 ` Paul Moore
2008-09-25 19:26   ` Tilman Baumann
2008-09-25 19:57     ` Paul Moore
2008-09-25 20:32       ` Tilman Baumann
2008-09-26 12:35   ` Tilman Baumann
2008-09-26 19:55     ` Paul Moore
2008-09-26  3:43 ` Casey Schaufler
2008-09-26  8:19   ` Tilman Baumann
2008-09-27  5:01     ` Casey Schaufler
2008-09-29 16:21       ` Tilman Baumann
2008-09-30  3:29         ` Casey Schaufler
2008-10-01 11:29           ` Tilman Baumann
2008-10-01 15:21             ` Casey Schaufler
2008-10-01 16:55               ` Tilman Baumann
2008-10-01 18:22                 ` Casey Schaufler
2008-10-06 12:57                   ` Tilman Baumann
2008-10-06 23:05                     ` Ahmed S. Darwish
2008-10-07  2:42                     ` Casey Schaufler [this message]
2008-10-17 16:57                       ` Tilman Baumann
2008-10-17 17:53                         ` Casey Schaufler
2008-10-20 12:06                           ` Tilman Baumann
2008-10-20 15:01                             ` Casey Schaufler
2008-10-22  3:36                             ` Casey Schaufler
2008-10-30 16:06                               ` Tilman Baumann
2008-10-31  3:46                                 ` Casey Schaufler
2008-12-11  0:03                                 ` Casey Schaufler
2008-12-11 10:18                                   ` Tilman Baumann
2008-12-11 16:29                                     ` Casey Schaufler
2008-10-23 11:55                           ` 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=48EACC91.8040008@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tilman.baumann@collax.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.