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: Wed, 01 Oct 2008 11:22:22 -0700 [thread overview]
Message-ID: <48E3BFDE.7010300@schaufler-ca.com> (raw)
In-Reply-To: <48E3AB97.8020305@collax.com>
Tilman Baumann wrote:
> Casey Schaufler wrote:
>> Tilman Baumann wrote:
>>> Casey Schaufler wrote:
>>>> Smack will eventually bite you if you're not careful, but users of
>>>> MAC systems wouldn't be surprised by that.
>>> Speaking of the devil...
>>> This is exactly what happened to me right now. I have problems with
>>> _some_ https connects. The problem lies somewhere in openssl.
>>> I did not yet find any clue with strace.
>>> Is there some straight forward way to audit/debug LSM interventions?
>>
>> strace is probably your best bet, as it will tell you what syscalls
>> fail. Your current situation is most likely a case where your program
>> running with a label "Foo" is trying to communicate with a service on
>> a machine that doesn't talk CIPSO and hence Smack is treating all
>> packets to and from that host with the ambient (%cat /smack/ambient)
>> label, which is "_" unless you've changed it.
>
> Yea, I just found that out.
> I did not expect smack to add netlabels by default. I thought I would
> need to configure something before it will start adding netlabels 'on
> the wire'.
It's pretty important to do it the way it is, because if a "Foo" process
can talk to port/host and a "Bar" process can talk to the same you can
pretty well assume that you have an information channel. I'm starting
to think about how I might go about allowing you to do it anyway.
> In my case 'security' is something that should only concern the local
> machine.
Unfortunately, any time you talk off the machine you have to consider that
the other machine(s) may not be very careful about information flows.
> Unfortunately I never bothered to test this before. :-/
>
> 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.
>
> btw. I find it very hard to find informations on the various files in
> /smack/ and it's respective intention and formating rules.
> security/smack/smackfs.c helps a bit.
If you pull down the smack-util-0.1 package from http://schaufler-ca.com
you will find programs that will do that formatting for you.
>
> This is my current setup:
> /smack/ambient (default)
> /smack/load = _ foo rwx
> Unlabeled process work fine.
> Labeled processes produce CIPSO labeled packets (which never get any
> answer anywhere from the internet)
>
> 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.
next prev parent reply other threads:[~2008-10-01 18:22 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 [this message]
2008-10-06 12:57 ` Tilman Baumann
2008-10-06 23:05 ` Ahmed S. Darwish
2008-10-07 2:42 ` Casey Schaufler
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=48E3BFDE.7010300@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox