Casey Schaufler wrote:Tilman Baumann wrote:Casey Schaufler wrote:Smack will eventually bite you if you're not careful, but users ofSpeaking of the devil...
MAC systems wouldn't be surprised by that.
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'.
In my case 'security' is something that should only concern the local machine.
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.
If you pull down the smack-util-0.1 package from http://schaufler-ca.com
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.
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)