SMACK netfilter smacklabel socket match - Kernel

This is a discussion on SMACK netfilter smacklabel socket match - Kernel ; Hi all, i made some SMACK related patches. I hope this list is the right place to post them. The intention behind this patch is that i needed a way to (firewall) match for packets originating from specific processes. The ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: SMACK netfilter smacklabel socket match

  1. SMACK netfilter smacklabel socket match

    Hi all,

    i made some SMACK related patches. I hope this list is the right place
    to post them.

    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.

    SMACK seemed to be the right way. So i made a little primitive netfilter
    match to match against the security context of sockets.
    SMACK does CIPSO labels, but this was not what i wanted, i wanted to
    label the socket not the packet (on the wire).
    This of course only works for packets with a local socket, but this was
    my intention anyway.

    This way i can label a process and all it's sockets carry the same label
    which i then can use to match against in the firewall.

    The code is pretty much based on cargo cult coding from other netfilter
    matches, especially the owner match (which turned out to be a bad
    reference since it is crapped with tons of compat interfaces).

    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.

    Originally i intended to put this mask in the xtables_match structure.
    ..hooks = (1 << NF_INET_LOCAL_OUT) | (1 << NF_INET_LOCAL_IN)
    But it turned out that i then could not longer put the rule in a chain
    which is called by the OUTPUT chain but only in OUTPUT directly.
    I did not investigate much more since i did not really understand this
    part. Allowing the user to add this match wherever he wants to does not
    hurt, if there is no local socket there is no matching.
    But maybe this is something that should be changed.

    About the Files:
    SMACK-netfilter-socket-label-match.patch
    is a git patch for the current kernel.

    iptables-smacklabel.patch
    contains the iptables userspace part (applies to iptables-1.4.1.1)


    Regards
    Tilman Baumann
    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942


  2. Re: SMACK netfilter smacklabel socket match

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


    Hello.

    > i made some SMACK related patches. I hope this list is the right
    > place to post them.


    Most Smack development has taken place on the LSM mailing list. At the
    very least I would recommend you CC the LSM list when sending Smack
    patches. I've taken the liberty of CC'ing both the LSM list and Casey
    on this email.

    > 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.

    > SMACK seemed to be the right way. So i made a little primitive
    > netfilter match to match against the security context of sockets.
    > SMACK does CIPSO labels, but this was not what i wanted, i wanted to
    > label the socket not the packet (on the wire).


    I would encourage you to look at selinux_ip_postroute() since it does
    exactly what you describe above using the SECMARK mechanism (in
    addition to other work). In particular look at the following code
    snippet:

    sk = skb->sk;
    if (sk) {
    struct sk_security_struct *sksec = sk->sk_security;
    peer_sid = sksec->sid;
    secmark_perm = PACKET__SEND;
    } else {
    if (selinux_skb_peerlbl_sid(skb, family, &peer_sid))
    return NF_DROP;
    secmark_perm = PACKET__FORWARD_OUT;
    }

    if (secmark_active)
    if (avc_has_perm(peer_sid, skb->secmark,
    SECCLASS_PACKET, secmark_perm, &ad))
    return NF_DROP;

    In the first if block you see that we are actually getting the security
    label from the socket, _not_ the packet, and then using that to perform
    the access control decision with avc_has_perm(). It should be easy to
    do the same with Smack and SECMARK.

    [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]

    > 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 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]

    Okay, I'll make a few comments on the kernel patch, you would probably
    want to ask the netfilter folks for comments on both patches. However,
    please keep in mind that I do not currently see a reason why you
    couldn't achieve your needs with the existing SECMARK code (with some
    modification/extension), please pursue that option before continuing
    with a dedicated SMACK target for netfilter.

    A few comments on your patch:

    > From 1c79c7c413dd3ebd72dbe12e1133037c6ea223af Mon Sep 17 00:00:00
    > 2001 From: Tilman Baumann
    > Date: Thu, 25 Sep 2008 19:07:37 +0200
    > Subject: [PATCH] SMACK netfilter socket label match
    >
    >
    > Signed-off-by: Tilman Baumann
    > ---
    > include/linux/netfilter/Kbuild | 1 +
    > include/linux/netfilter/xt_smack.h | 21 +++++++++
    > net/netfilter/Kconfig | 10 +++++
    > net/netfilter/Makefile | 1 +
    > net/netfilter/xt_smack.c | 79
    > ++++++++++++++++++++++++++++++++++++ 5 files changed, 112
    > insertions(+), 0 deletions(-)
    > create mode 100644 include/linux/netfilter/xt_smack.h
    > create mode 100644 net/netfilter/xt_smack.c


    ....

    > --- /dev/null
    > +++ b/net/netfilter/xt_smack.c
    > @@ -0,0 +1,79 @@
    > +/*
    > + * Kernel module to match against SMACK labels
    > + *
    > + * (C) 2008 Tilman Baumann
    > + *
    > + * This program is free software; you can redistribute it and/or
    > modify + * it under the terms of the GNU General Public License
    > version 2 as + * published by the Free Software Foundation.
    > + */
    > +#include
    > +#include
    > +#include
    > +#include
    > +#include
    > +#include
    > +#include <../security/smack/smack.h>


    If you need a Smack specific interface you shouldn't include a file from
    security/smack, instead you should use/create an interface in
    include/linux/smack.h. In this particular case this would mean
    creating the file.

    > +static bool
    > +smack_mt(const struct sk_buff *skb, const struct net_device *in,
    > + const struct net_device *out, const struct xt_match *match,
    > + const void *matchinfo, int offset, unsigned int protoff,
    > + bool *hotdrop)
    > +{
    > + const struct xt_smack_match_info *info = matchinfo;
    > + struct socket_smack *smacks;
    > +
    > + if (skb->sk == NULL || skb->sk->sk_socket == NULL)
    > + return (info->mask ^ info->invert) == 0;
    > + smacks = skb->sk->sk_security;
    > + if (smacks == NULL){
    > + return (info->mask ^ info->invert);
    > + }
    > +
    > + if(info->mask & XT_SMACK_IN){
    > + return ! ((!strncmp(smacks->smk_in, info->match_in, SMK_LABELLEN))
    > ^ + (info->invert & XT_SMACK_IN));
    > + }
    > +
    > + if(info->mask & XT_SMACK_OUT){
    > + return ! ((!strncmp(smacks->smk_in, info->match_out,
    > SMK_LABELLEN)) ^ + (info->invert & XT_SMACK_OUT));
    > + }
    > +
    > + if(info->mask & XT_SMACK_PEER){
    > + return ! ((!strncmp(smacks->smk_packet, info->match_peer_packet,
    > SMK_LABELLEN)) ^ + (info->invert & XT_SMACK_IN));
    > + }


    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.

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

  3. 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: SMACK netfilter smacklabel socket match

    On Thursday 25 September 2008 3:26:40 pm Tilman Baumann wrote:
    > 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.


    With SELinux the packet's CIPSO label (called the packet's peer label)
    is different from the SECMARK label. Assuming you take a similar
    approach in Smack, you should be able to implement SECMARK without
    having to every concern yourself with the CIPSO label.

    > >> 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.


    Yes, in the absence of the sending socket to obtain the packet's peer
    label you need to examine the packet itself and any labeling
    information present on the packet; in the case of Smack this is CIPSO.

    > > 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.


    Well, if you are accepting or dropping packets you are applying some
    form of access control. I thought that was the point of your patch?
    If not perhaps I misunderstood or assumed too much.

    > 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.


    Hmmm, the term "capability" is probably not the best term to use, but
    there are valid reasons to use the netfilter mechanism, i.e. SECMARK,
    to apply a network label to both incoming and outgoing packets. The
    idea is that this allows the LSM to make network access control
    decisions based on the network attributes of a packet (address,
    protocol, port, etc.) and the powerful packet/connection matching
    mechanisms in netfilter.

    > 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.


    I think I understand you goal now, essentially you want to route traffic
    based on the security label of the sender, yes? There was some brief
    talk about this at the SELinux Developer's Summit this year at OLS.
    Unfortunately, it was just a casual conversation and I haven't seen any
    patches since then implementing security label based routing.

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

  5. Re: SMACK netfilter smacklabel socket match

    Am 25.09.2008 um 21:57 schrieb Paul Moore:
    >>
    >> 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.

    >
    > I think I understand you goal now, essentially you want to route
    > traffic
    > based on the security label of the sender, yes? There was some brief
    > talk about this at the SELinux Developer's Summit this year at OLS.
    > Unfortunately, it was just a casual conversation and I haven't seen
    > any
    > patches since then implementing security label based routing.


    Wow, now it strikes me that i was running around blind all the time.
    SECMARK is a target not a match.
    I always thought i would implementing much the same thing.

    I guess there would be in fact currently not way to set a MARK or
    CONNMAK
    based on a SECMARK. Most of the *MARK targets have a --restore-mark
    option
    to restore a mark into the packet mark.
    But since the SECMARK is not numeric/bitmask there is nothing to
    restore.
    They however can do the same in regard do CONNSECMARK and SECMARK
    but which would not help in this case.
    A secmark netfilter _match_ could do the trick here.

    Well here is how i did this, maybe something like this is the way to
    go for
    SELinux (or LSM in general) too.

    I'm surprised that i have not realized this little detail before. :-/

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

  6. Re: SMACK netfilter smacklabel socket match

    Tilman Baumann wrote:
    > Hi all,
    >
    > i made some SMACK related patches. I hope this list is the right place
    > to post them.


    Here and, probably more importantly
    linux-security-module@vger.kernel.org as that's
    my primary hang out.

    > 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.
    >
    > SMACK seemed to be the right way. So i made a little primitive
    > netfilter match to match against the security context of sockets.
    > SMACK does CIPSO labels, but this was not what i wanted, i wanted to
    > label the socket not the packet (on the wire).
    > This of course only works for packets with a local socket, but this
    > was my intention anyway.
    >
    > This way i can label a process and all it's sockets carry the same
    > label which i then can use to match against in the firewall.
    >


    Hmm. It looks as if your code will do what you're asking it to do.
    Are you going to be happy with the access restrictions that will be
    imposed by Smack?

    > The code is pretty much based on cargo cult coding from other
    > netfilter matches, especially the owner match (which turned out to be
    > a bad reference since it is crapped with tons of compat interfaces).
    >
    > 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.
    >
    > Originally i intended to put this mask in the xtables_match structure.
    > .hooks = (1 << NF_INET_LOCAL_OUT) | (1 << NF_INET_LOCAL_IN)
    > But it turned out that i then could not longer put the rule in a chain
    > which is called by the OUTPUT chain but only in OUTPUT directly.
    > I did not investigate much more since i did not really understand this
    > part. Allowing the user to add this match wherever he wants to does
    > not hurt, if there is no local socket there is no matching.
    > But maybe this is something that should be changed.
    >
    > About the Files:
    > SMACK-netfilter-socket-label-match.patch
    > is a git patch for the current kernel.
    >
    > iptables-smacklabel.patch
    > contains the iptables userspace part (applies to iptables-1.4.1.1)
    >
    >
    > Regards
    > Tilman Baumann


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

  7. Re: SMACK netfilter smacklabel socket match

    Am 26.09.2008 um 05:43 schrieb Casey Schaufler:

    > Tilman Baumann wrote:
    >> Hi all,
    >>
    >> i made some SMACK related patches. I hope this list is the right
    >> place to post them.

    >
    > Here and, probably more importantly linux-security-module@vger.kernel.org
    > as that's
    > my primary hang out.
    >
    >> 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.
    >>
    >> SMACK seemed to be the right way. So i made a little primitive
    >> netfilter match to match against the security context of sockets.
    >> SMACK does CIPSO labels, but this was not what i wanted, i wanted
    >> to label the socket not the packet (on the wire).
    >> This of course only works for packets with a local socket, but this
    >> was my intention anyway.
    >>
    >> This way i can label a process and all it's sockets carry the same
    >> label which i then can use to match against in the firewall.
    >>

    >
    > Hmm. It looks as if your code will do what you're asking it to do.
    > Are you going to be happy with the access restrictions that will be
    > imposed by Smack?


    I helped myself with rules like this.
    _ foo rwx
    But i wanted to add some security stuff like selinux for years,
    and SMACK seems to be just great.
    So i will spend some time making security rules after i got this routing
    stuff to work.

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

  8. Re: SMACK netfilter smacklabel socket match

    Paul Moore wrote:

    > [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]


    Can you give me a pointer where to look?

    Will this mean that skb->sk may be invalid or that it will point to a a
    context based on the network label the packet has?
    In the later case, being able to match remote labels in my match would
    just give added benefit. (Though a netlabel (CIPSO) match would probably
    be more sane than a smack specific match.)
    One would just have more choices where to put a rule like this. Like in
    the FORWARD chain.
    If non local packets are of no interest, one could put the rule in the
    right chain.

    But i think i just misunderstood you here. Since having a socket for non
    local packets is probably not what you meant.

    Regards
    Tilman
    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: SMACK netfilter smacklabel socket match

    On Friday 26 September 2008 8:35:12 am Tilman Baumann wrote:
    > Paul Moore wrote:
    > > [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]

    >
    > Can you give me a pointer where to look?


    Sure. You want to look at the selinux_ip_postroue() function which is
    located in the security/selinux/hooks.c file in a patched version of
    the kernel. The particular patch you need can be found here:

    * http://marc.info/?l=linux-security-m...6989812425&w=2

    You can grab the patch (and others in the queue for 2.6.28) from the
    labeled networking git tree located here:

    * http://git.infradead.org/users/pcmoo...et-2.6_testing
    * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing

    > Will this mean that skb->sk may be invalid or that it will point to a
    > a context based on the network label the packet has?


    No. It just means that if the skb->sk pointer is NULL the packet might
    not actually be for another system, i.e. a forwarded packet. It turns
    out there are a few places in the kernel that send packets without an
    associated socket. If you look towards the very bottom of the patch I
    referenced at the top of this email you will see the following
    code/patch which should now handle this case correctly for SELinux.
    Smack is unaffected because of it's current network access controls.

    You want to pay attention to how the 'peer_sid' value is derived as this
    is the SELinux "security label".

    [NOTE: I hacked up the diff below a bit so it is a bit cleaner in this
    email]

    @@ -4574,21 +4586,45 @@ static unsigned int selinux_ip_postroute(struct
    if (!secmark_active && !peerlbl_active)
    return NF_ACCEPT;

    - /* if the packet is locally generated (skb->sk != NULL) then use
    - * socket's label as the peer label, otherwise the packet is
    - * forwarded through this system and we need to fetch the peer
    - * directly from the packet */
    + /* if the packet is being forwarded then get the peer label from
    + * packet itself; otherwise check to see if it is from a local
    + * application or the kernel, if from an application get the
    + * from the sending socket, otherwise use the kernel's sid */
    sk = skb->sk;
    - if (sk) {
    + if (sk == NULL) {
    + switch (family) {
    + case PF_INET:
    + if (IPCB(skb)->flags & IPSKB_FORWARDED)
    + secmark_perm = PACKET__FORWARD_OUT;
    + else
    + secmark_perm = PACKET__SEND;
    + break;
    + case PF_INET6:
    + if (IP6CB(skb)->flags & IP6SKB_FORWARDED)
    + secmark_perm = PACKET__FORWARD_OUT;
    + else
    + secmark_perm = PACKET__SEND;
    + break;
    + default:
    + return NF_DROP;
    + }
    + if (secmark_perm == PACKET__FORWARD_OUT) {
    + if (selinux_skb_peerlbl_sid(skb,..., &peer_sid);
    + return NF_DROP;
    + } else
    + peer_sid = SECINITSID_KERNEL;
    + } else {
    struct sk_security_struct *sksec = sk->sk_security;
    peer_sid = sksec->sid;
    secmark_perm = PACKET__SEND;
    - } else {
    - if (selinux_skb_peerlbl_sid(skb, family, &peer_sid))
    - return NF_DROP;
    - secmark_perm = PACKET__FORWARD_OUT;
    }

    > In the later case, being able to match remote labels in my match
    > would just give added benefit. (Though a netlabel (CIPSO) match would
    > probably be more sane than a smack specific match.)
    > One would just have more choices where to put a rule like this. Like
    > in the FORWARD chain.
    > If non local packets are of no interest, one could put the rule in
    > the right chain.


    I've been thinking a little more about the idea of using a packet's peer
    security label as a netfilter match and I have one major concern: if we
    allow netfilter to match on a packet's peer security label[1] then we
    are opening the door for administrators to arbitrarily apply label
    based security policy regardless of the LSM's security policy. For
    many reasons beyond the scope of this discussion thread this is a Bad
    Idea, which makes me nervous about providing such a general matching
    function. If you are interested in pursuing this further I would
    definitely need more discussion around this point.

    [1] Matching on the packet's SECMARK security label is equally bad, but
    also somewhat pointless since the SECMARK security label is defined by
    netfilter already, why not just have the original netfilter SECMARK
    rule do whatever you wanted in the first place? In other words, you
    don't need SECMARK for this particular case.

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

  10. Re: SMACK netfilter smacklabel socket match

    Tilman Baumann wrote:
    > Am 26.09.2008 um 05:43 schrieb Casey Schaufler:
    >
    >> Tilman Baumann wrote:
    >>> Hi all,
    >>>
    >>> i made some SMACK related patches. I hope this list is the right
    >>> place to post them.

    >>
    >> Here and, probably more importantly
    >> linux-security-module@vger.kernel.org as that's
    >> my primary hang out.
    >>
    >>> 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.
    >>>
    >>> SMACK seemed to be the right way. So i made a little primitive
    >>> netfilter match to match against the security context of sockets.
    >>> SMACK does CIPSO labels, but this was not what i wanted, i wanted to
    >>> label the socket not the packet (on the wire).
    >>> This of course only works for packets with a local socket, but this
    >>> was my intention anyway.
    >>>
    >>> This way i can label a process and all it's sockets carry the same
    >>> label which i then can use to match against in the firewall.
    >>>

    >>
    >> Hmm. It looks as if your code will do what you're asking it to do.
    >> Are you going to be happy with the access restrictions that will be
    >> imposed by Smack?

    >
    > I helped myself with rules like this.
    > _ foo rwx
    > But i wanted to add some security stuff like selinux for years,
    > and SMACK seems to be just great.
    > So i will spend some time making security rules after i got this routing
    > stuff to work.
    >

    I confess that I'm still not completely sure what you're up too,
    but you might want to look at smackpolyport (it's in the smack-util
    tarball) and might make your life easier if you want to have a
    single server (running at foo) that deals with connections from
    processes with multiple labels.


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

  11. Re: SMACK netfilter smacklabel socket match



    Casey Schaufler wrote:
    > Tilman Baumann wrote:


    >>> Hmm. It looks as if your code will do what you're asking it to do.
    >>> Are you going to be happy with the access restrictions that will be
    >>> imposed by Smack?

    >>
    >> I helped myself with rules like this.
    >> _ foo rwx
    >> But i wanted to add some security stuff like selinux for years,
    >> and SMACK seems to be just great.
    >> So i will spend some time making security rules after i got this routing
    >> stuff to work.
    >>

    > I confess that I'm still not completely sure what you're up too,
    > but you might want to look at smackpolyport (it's in the smack-util
    > tarball) and might make your life easier if you want to have a
    > single server (running at foo) that deals with connections from
    > processes with multiple labels.


    I'm essentially using this as some kind of iptables owner-match on steroids.
    Owner match allows to filter on the processes uid, gid, and some other
    process attributes.
    Unfortunately owner match is pretty much useless because of it's limited
    matching capabilities.

    I'm really just abusing the way how security contexts of processes are
    transfered to all it's sockets.
    This way I can label a process with a specific label which then gets
    transfered to all of it's sockets.
    With this match I can look at the label via the socket of any packet in
    iptables.
    I'm pretty much ignoring the Security aspect of SMACK right now and
    just use it as some label that I can stick to processes.

    What I then to is write iptables OUTPUT chain matches which match for
    any of these labels and set some connection marks and firewall marks.
    Which I then can use in routing rules to give different routing rules to
    specific processes. (Like all proxy traffic over a second DSL line)

    I know, it's totally crazy. But it seems to work.
    I just hope the security part of this all will not break anything. But
    it does not look like it would right now.

    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: SMACK netfilter smacklabel socket match

    Tilman Baumann wrote:
    >
    >
    > Casey Schaufler wrote:
    >> Tilman Baumann wrote:

    >
    >>>> Hmm. It looks as if your code will do what you're asking it to do.
    >>>> Are you going to be happy with the access restrictions that will be
    >>>> imposed by Smack?
    >>>
    >>> I helped myself with rules like this.
    >>> _ foo rwx
    >>> But i wanted to add some security stuff like selinux for years,
    >>> and SMACK seems to be just great.
    >>> So i will spend some time making security rules after i got this
    >>> routing
    >>> stuff to work.
    >>>

    >> I confess that I'm still not completely sure what you're up too,
    >> but you might want to look at smackpolyport (it's in the smack-util
    >> tarball) and might make your life easier if you want to have a
    >> single server (running at foo) that deals with connections from
    >> processes with multiple labels.

    >
    > I'm essentially using this as some kind of iptables owner-match on
    > steroids.
    > Owner match allows to filter on the processes uid, gid, and some other
    > process attributes.
    > Unfortunately owner match is pretty much useless because of it's
    > limited matching capabilities.
    >
    > I'm really just abusing the way how security contexts of processes are
    > transfered to all it's sockets.
    > This way I can label a process with a specific label which then gets
    > transfered to all of it's sockets.
    > With this match I can look at the label via the socket of any packet
    > in iptables.
    > I'm pretty much ignoring the Security aspect of SMACK right now and
    > just use it as some label that I can stick to processes.
    >


    If you really want to be abusive you could replace the smack_access()
    function in security/smack/smack_access.c (of all places) with a no-op
    returning 0 in all cases.

    > What I then to is write iptables OUTPUT chain matches which match for
    > any of these labels and set some connection marks and firewall marks.
    > Which I then can use in routing rules to give different routing rules
    > to specific processes. (Like all proxy traffic over a second DSL line)
    >
    > I know, it's totally crazy. But it seems to work.
    > I just hope the security part of this all will not break anything. But
    > it does not look like it would right now.


    Smack will eventually bite you if you're not careful, but users of
    MAC systems wouldn't be surprised by that. I don't think it's crazy,
    I think it's a matter of using what's available in novel ways. Don't
    hesitate if there's anything I can do to be helpful.

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

  13. Re: SMACK netfilter smacklabel socket match

    Casey Schaufler wrote:
    >> Casey Schaufler wrote:

    > If you really want to be abusive you could replace the smack_access()
    > function in security/smack/smack_access.c (of all places) with a no-op
    > returning 0 in all cases.


    I thought of that too.
    But i would rather like to use the thing in it's intended function
    sometime in the future.

    >> What I then to is write iptables OUTPUT chain matches which match for
    >> any of these labels and set some connection marks and firewall marks.
    >> Which I then can use in routing rules to give different routing rules
    >> to specific processes. (Like all proxy traffic over a second DSL line)
    >>
    >> I know, it's totally crazy. But it seems to work.
    >> I just hope the security part of this all will not break anything. But
    >> it does not look like it would right now.

    >
    > 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?

    I have probably missed something that a labeled process could not do as
    a '_' process could. Have no idea right now, but it is probably
    something stupidly simple.

    > I don't think it's crazy,
    > I think it's a matter of using what's available in novel ways.

    I like that attitude.

    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: SMACK netfilter smacklabel socket match

    Tilman Baumann wrote:
    > Casey Schaufler wrote:
    >>> Casey Schaufler wrote:

    >> If you really want to be abusive you could replace the smack_access()
    >> function in security/smack/smack_access.c (of all places) with a no-op
    >> returning 0 in all cases.

    >
    > I thought of that too.
    > But i would rather like to use the thing in it's intended function
    > sometime in the future.


    Even better.


    >>> What I then to is write iptables OUTPUT chain matches which match
    >>> for any of these labels and set some connection marks and firewall
    >>> marks.
    >>> Which I then can use in routing rules to give different routing
    >>> rules to specific processes. (Like all proxy traffic over a second
    >>> DSL line)
    >>>
    >>> I know, it's totally crazy. But it seems to work.
    >>> I just hope the security part of this all will not break anything.
    >>> But it does not look like it would right now.

    >>
    >> 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.

    > I have probably missed something that a labeled process could not do
    > as a '_' process could. Have no idea right now, but it is probably
    > something stupidly simple.
    >


    A labeled system hoping to get services from an unlabeled server is the
    biggest
    single pain in dealing with labeled systems. Per-host labeling is in the
    works,
    and it will help in some cases. What I really need is a way to designate an
    unlabeled host as safe to talk to at any label, but it will take some
    serious
    work to come up with a scheme that makes that palatable for a labeled
    environment.
    I know that SELinux allows for it, but the purist in me has serious doubts.

    >> I don't think it's crazy,
    >> I think it's a matter of using what's available in novel ways.

    > I like that attitude.


    It got me where I am today. Hmm, maybe you should be just a little bit
    careful.

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

  15. Re: SMACK netfilter smacklabel socket match

    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'.
    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.

    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)

    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: SMACK netfilter smacklabel socket match

    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.

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

  17. Re: SMACK netfilter smacklabel socket match

    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.

    >> 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.
    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.

    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: SMACK netfilter smacklabel socket match

    Hi Tilman,

    On Mon, Oct 6, 2008 at 2:57 PM, Tilman Baumann
    wrote:
    > If I set /smack/nltype to 'unlabeled' I have effectively shut off the
    > network.

    ....
    > This might work well in trusted networks.
    > But Internet is untrusted and needs to work too. At least in the most real
    > world scenarios.
    >
    > 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.


    Check this patch:
    http://article.gmane.org/gmane.linux...k/95294/match=

    As far as I can remember, it does exactly what you're asking for.
    There have been some arguments against it, but at least you can get
    the idea and _try_ to discuss/enhance it further.

    Regards

    --
    Ahmed S. Darwish
    Homepage: http://darwish.07.googlepages.com
    Blog: http://darwish-07.blogspot.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: SMACK netfilter smacklabel socket match

    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.
    >


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

  20. Re: SMACK netfilter smacklabel socket match

    Hi Casey,

    the last weeks I tried to come up with some way to circumvent my
    problems by aimlessly poking around in the code. Did not work though.
    Not yet at least.
    Maybe it makes more sense for me to wait until you have a solution.
    My whole project is stalled right now because of this and I'm not sure
    what next.
    Do you plan to change something there soon? If so I would stop wasting
    my time with hopeless attempts.

    My problem is at the moment that I don't really know what to do. If you
    can give some aim I would be glad if I could do something.

    Thanks

    Casey Schaufler wrote:
    > Tilman Baumann wrote:
    >> Casey Schaufler wrote:
    >>> Tilman Baumann wrote:

    >> 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.



    --
    Tilman Baumann
    Software Developer
    Collax GmbH . Boetzinger Strasse 60 . 79111 Freiburg . Germany

    p: +49 (0) 89-990157-0
    f: +49 (0) 89-990157-11

    Geschaeftsfuehrer: William K. Hite / Boris Nalbach
    AG Muenchen HRB 158898, Ust.-IdNr: DE 814464942
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast