This is a discussion on SMACK netfilter smacklabel socket match - Kernel ; Tilman Baumann wrote:
> 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.
...
Tilman Baumann wrote:
> 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.
Well, the good news is that I have a change under test that will address
your needs, allowing a host or set of hosts to be generally accessible
from the Smack system. The bad news is that it uses a set of netlabel
apis that are not going to get released in favor of a redesigned set of
apis which are not available yet. The good news is that those apis will
handle Smack's needs just fine, but again the bad news is that I don't
have them to use yet.
If you're up to trying out something that you know is going to get
rewhacked before it goes in anywhere let me know.
Casey Schaufler wrote:
> Tilman Baumann wrote:
>> 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.
>
> Well, the good news is that I have a change under test that will address
> your needs, allowing a host or set of hosts to be generally accessible
> from the Smack system. The bad news is that it uses a set of netlabel
> apis that are not going to get released in favor of a redesigned set of
> apis which are not available yet. The good news is that those apis will
> handle Smack's needs just fine, but again the bad news is that I don't
> have them to use yet.
>
> If you're up to trying out something that you know is going to get
> rewhacked before it goes in anywhere let me know.
Sure. I will be happy to use that.
Just tell me where to find it and how to use it and what I should look
out for.
Tilman Baumann wrote:
>> If you're up to trying out something that you know is going to get
>> rewhacked before it goes in anywhere let me know.
>
> Sure. I will be happy to use that.
> Just tell me where to find it and how to use it and what I should look
> out for.
>
OK. I'll throw a patch together. It may take a day or two due
to the heap on my plate.
Tilman Baumann wrote:
>> If you're up to trying out something that you know is going to get
>> rewhacked before it goes in anywhere let me know.
>
> Sure. I will be happy to use that.
> Just tell me where to find it and how to use it and what I should look
> out for.
>
You'll need to start out with Paul Moore's testing tree:
Apply the attached patch (attachments are discouraged for review purposes,
but this is handier for this purpose) and compile.
This is NOT production code. Again, we're hashing out the netlabel api and
we know that they are going to change. This is demo only. The amount of
testing it's gotten is really small.
I have created a new system label "@", pronounced "at" and referred to as
the internet label. Processes cannot be assigned the internet label. A
subject with the internet label (as identified by a packet thus labeled)
can write to any object and any subject can write to an object thus labeled,
thereby explicitly blowing a hole in the Access Control Policy.
/*
* The initial value needs to be bigger than any of the
@@ -99,6 +106,16 @@ int smk_access(char *subject_label, char
strcmp(subject_label, smack_known_star.smk_known) == 0)
return -EACCES;
/*
+ * An internet object can be accessed by any subject.
+ * Tasks cannot be assigned the internet label.
+ * An internet subject can access any object.
+ */
+ if (object_label == smack_known_internet.smk_known ||
+ subject_label == smack_known_internet.smk_known ||
+ strcmp(object_label, smack_known_internet.smk_known) == 0 ||
+ strcmp(subject_label, smack_known_internet.smk_known) == 0)
+ return 0;
+ /*
* A star object can be accessed by any subject.
*/
if (object_label == smack_known_star.smk_known ||
diff -uprN -X lblnet-2.6_testing/Documentation/dontdiff lblnet-2.6_testing/security/smack/smackfs.c lblnet-2.6-1011/security/smack/smackfs.c
--- lblnet-2.6_testing/security/smack/smackfs.c 2008-10-07 10:56:47.000000000 -0700
+++ lblnet-2.6-1011/security/smack/smackfs.c 2008-10-12 12:59:36.000000000 -0700
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -39,6 +40,8 @@ enum smk_inos {
SMK_DIRECT = 6, /* CIPSO level indicating direct label */
SMK_AMBIENT = 7, /* internet ambient label */
SMK_NLTYPE = 8, /* label scheme to use by default */
+ SMK_ONLYCAP = 9, /* the only "capable" label */
+ SMK_SLHOST = 10, /* single label hosts */
};
/*
* This is the "ambient" label for network traffic.
@@ -68,6 +72,23 @@ int smack_net_nltype = NETLBL_NLTYPE_CIP
*/
int smack_cipso_direct = SMACK_CIPSO_DIRECT_DEFAULT;
+/*
+ * Unless a process is running with this label even
+ * having CAP_MAC_OVERRIDE isn't enough to grant
+ * privilege to violate MAC policy. If no label is
+ * designated (the NULL case) capabilities apply to
+ * everyone. It is expected that the hat (^) label
+ * will be used if any label is used.
+ */
+char *smack_onlycap;
+
+/*
+ * Certain IP addresses may be designated as single label hosts.
+ * Packets are sent there unlabeled, but only from tasks that
+ * can write to the specified label.
+ */
+struct smk_slhost *smack_slhosts;
+
static int smk_cipso_doi_value = SMACK_CIPSO_DOI_DEFAULT;
struct smk_list_entry *smack_list;
+/*
+ * Seq_file read operations for /smack/slhost
+ */
+
+static void *slhost_seq_start(struct seq_file *s, loff_t *pos)
+{
+ if (*pos == SEQ_READ_FINISHED)
+ return NULL;
+
+ return smack_slhosts;
+}
+
+static void *slhost_seq_next(struct seq_file *s, void *v, loff_t *pos)
+{
+ struct smk_slhost *skp = ((struct smk_slhost *) v)->smk_next;
+
+ if (skp == NULL)
+ *pos = SEQ_READ_FINISHED;
+
+ return skp;
+}
+
+/*
+ * Print host/label pairs
+ */
+static int slhost_seq_show(struct seq_file *s, void *v)
+{
+ struct smk_slhost *skp = (struct smk_slhost *) v;
+ unsigned char *hp = (char *) &skp->smk_host.sin_addr.s_addr;
+
+ seq_printf(s, "%u.%u.%u.%u %s\n", hp[0], hp[1], hp[2], hp[3],
+ skp->smk_label);
+
+ return 0;
+}
+
+static void slhost_seq_stop(struct seq_file *s, void *v)
+{
+ /* No-op */
+}
+
+static struct seq_operations slhost_seq_ops = {
+ .start = slhost_seq_start,
+ .stop = slhost_seq_stop,
+ .next = slhost_seq_next,
+ .show = slhost_seq_show,
+};
+
+/**
+ * smk_open_slhost - open() for /smack/slhost
+ * @inode: inode structure representing file
+ * @file: "slhost" file pointer
+ *
+ * Connect our slhost_seq_* operations with /smack/slhost
+ * file_operations
+ */
+static int smk_open_slhost(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &slhost_seq_ops);
+}
+
+/**
+ * smk_write_slhost - write() for /smack/slhost
+ * @filp: file pointer, not actually used
+ * @buf: where to get the data from
+ * @count: bytes sent
+ * @ppos: where to start
+ *
+ * Accepts only one slhost per write call.
+ * Returns number of bytes written or error code, as appropriate
+ */
+static ssize_t smk_write_slhost(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct smk_slhost *skp;
+ struct sockaddr_in newname;
+ char smack[SMK_LABELLEN];
+ char *sp;
+ char data[SMK_SLHOSTMAX];
+ char *host = (char *)&newname.sin_addr.s_addr;
+ int rc;
+ int replace = 1;
+ struct netlbl_audit audit_info;
+ struct in_addr mask;
+ unsigned int m = 32;
+ __be32 bebits = 0x80000000;
+ __be32 nsa;
+
+ /*
+ * Must have privilege.
+ * No partial writes.
+ * Enough data must be present.
+ * "
Re: SMACK netfilter smacklabel socket match
On Friday 17 October 2008 1:53:38 pm Casey Schaufler wrote:
> Tilman Baumann wrote:
> > 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.
>
> Well, the good news is that I have a change under test that will
> address your needs, allowing a host or set of hosts to be generally
> accessible from the Smack system. The bad news is that it uses a set
> of netlabel apis that are not going to get released in favor of a
> redesigned set of apis which are not available yet. The good news is
> that those apis will handle Smack's needs just fine, but again the
> bad news is that I don't have them to use yet.
Just a quick update. You can blame me for the delay, I was a bit
distracted trying to get things ready for the 2.6.28 merge window and
the NetLabel kernel API changes got pushed aside for a few weeks. I
just sent Casey a draft patch of the new API bits to review; with any
luck I'll have something to post as an RFC patch shortly.
Casey Schaufler wrote:
> Tilman Baumann wrote:
>>> If you're up to trying out something that you know is going to get
>>> rewhacked before it goes in anywhere let me know.
>>
>> Sure. I will be happy to use that.
>> Just tell me where to find it and how to use it and what I should look
>> out for.
>>
>
> You'll need to start out with Paul Moore's testing tree:
>
> % git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing
>
> Apply the attached patch (attachments are discouraged for review purposes,
> but this is handier for this purpose) and compile.
>
> This is NOT production code. Again, we're hashing out the netlabel api and
> we know that they are going to change. This is demo only. The amount of
> testing it's gotten is really small.
>
> I have created a new system label "@", pronounced "at" and referred to as
> the internet label. Processes cannot be assigned the internet label. A
> subject with the internet label (as identified by a packet thus labeled)
> can write to any object and any subject can write to an object thus
> labeled,
> thereby explicitly blowing a hole in the Access Control Policy.
>
> Have fun, let me know what you hit next.
Sorry for the long delay. I was annoyingly occupied with other things.
I just tried this out. But one thing makes me wonder if I had understood
what it should do.
The syntax for /smack/slhost is IP[/MASK] LABEL.
When I give one host (in my case generously 0.0.0.0/0 *g*) a label what
is the significance of the @ label?
First I used the _ label here which had the effect that everything seems
to work but labeled processes still produced labeled packet which got
slaughtered in different ways and degrees over the internet.
If I gave my slhost the @ label my machine was offline and did not even
get pings out locally.
I get the feeling I did not understand the concept yet.
Sorry but if you don't mind giving me a hint...