linux-kernel - Re: SMACK netfilter smacklabel socket match

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <89D091CB-9AE1-4792-AD3F-98754AF13C19@collax.com>
Date:	Thu, 25 Sep 2008 21:26:40 +0200
From:	Tilman Baumann <tilman.baumann@...lax.com>
To:	Paul Moore <paul.moore@...com>
Cc:	Linux-Kernel <linux-kernel@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	linux-security-module@...r.kernel.org
Subject: Re: SMACK netfilter smacklabel socket match

Am 25.09.2008 um 20:26 schrieb Paul Moore:

> On Thursday 25 September 2008 1:25:53 pm Tilman Baumann wrote:

>
>> The intention behind this patch is that i needed a way to (firewall)
>> match for packets originating from specific processes.
>> The existing owner match did not work well enough, especially since
>> the cmd-owner part is removed.
>> Then i thought about a way to tag processes and somehow match this
>> tag in the firewall.
>> I recalled that SELinux can do this (SECMARK) but SELinux would have
>> been way to complex for what i want. But the idea was born, i just
>> needed something more simple.
>
> It appears the simplest option would be to provide the necessary  
> SECMARK
> support in Smack.  SECMARK has provisions for supporting different
> types of LSMs and adding Smack support should be relatively trivial.
> In fact, it is possible for SECMARK to be made entirely LSM agnostic
> and have it deal strictly with secctx/label and secid/token values.   
> We
> would need to retain the SELinux specific interface for
> legacy/compatibility reasons but I would encourage new patches to take
> this more general approach rather than LSM specific extension.

Sounds like a good idea. When i looked at the SECMARK code i could not  
get my
head around the SELinux specific stuff, so i discarded the idea as to  
complex.

For this to be complete i guess the CIPSO labels for SMACK would need
to be taken into account.
Far more than my quick and dirty approach, and probably more than i'm  
the
right person to do it.
Il try to understand the inner workings of the SECMARK stuff tough.

I will come back to your other comments tomorrow.

> [NOTE: you may notice the above code changing slightly in future
> kernels, it turns out that skb->sk == NULL is not a true indicator  
> of a
> non-local sender, see my labeled networking patches for 2.6.28 or
> linux-next for the revised approach]
Good to know.

>> This of course only works for packets with a local socket, but this
>> was my intention anyway.
>
> You could also expand it to handle non-local senders.  However, from  
> my
> discussions with Casey about Smack and network access controls,
> enforcing policy against forwarded traffic is not something he is
> interested in at this point.

I have not investigated further into that, but if there is some way to
match on CIPSO labels, there would be at least a vehicle to base this  
on.

>> I have no kernel coding experience whatsoever and little C coding
>> history. So i would really like you guys to look over it a bit.
>
> [NOTE: you will want to post your patches inline in the future,  
> sending
> patches as attachments are frowned upon]
ok

> I don't like how the access control is being done outside of the Smack
> LSM; once again I would encourage you to further investigate the
> approach taken by SECMARK.  If you must do access control outside of
> the LSM then please at least abstract the actual access control
> decision, in this case strncmp(), to a LSM interface.

Access control was actually not what i needed in this case.
This would in this case as far as i know actually be done in the SMACK  
LSM.
I'm not sure how much it would make sense to base firewall decisions on
capability checks (i guess this is what you referring to).
Like decisions in the form of who/what may access a process in which  
way.
Please correct me if i understood you wrong.

What i do with this match is just setting some CONNMARK and respectively
FWMARKS to make crazy routing rules for different kinds (marked  
processes)
of my outgoing traffic based on them.


Regards
  Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/