On Wednesday, January 18, 2017 7:32:40 AM EST Paul Moore wrote: > On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > On 2017-01-17 21:34, Richard Guy Briggs wrote: > >> On 2017-01-17 15:17, Paul Moore wrote: > >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > >> > > On 2017-01-17 08:55, Steve Grubb wrote: > >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote: > >> > ... > >> > > >> > >> > Ones that are not so straightforward: > >> > >> > - "secmark" depends on a kernel config setting, so should it > >> > >> > always be > >> > >> > > >> > >> > present but "(none)" if that kernel feature is compiled out? > >> > >> > >> > >> If this is selinux related, I'd treat it the same way that we do > >> > >> subj > >> > >> everywhere else. > >> > > > >> > > Ok. > >> > > >> > To be clear, a packet's secmark should be recorded via a dedicated > >> > field, e.g. "secmark", and not use the "subj" field (it isn't a > >> > subject label in the traditional sense). > >> > >> I think Steve was talking about if, when or where to include that field, > >> not what its label is. > > > > In this case it is an "obj=" field, but since it is part of the LSM, > > each one has its own fields. > > As I said above, use a "secmark" field and not the subject or object > fields; packet labeling is rather complex and there is value in > differentiating between secmark labels and network peer labels. As Richard said, I was talking about when to include it, not what to include. Context labels go through this test to check if there is a secid and log context information if its there. This keeps the logs self consistent if a MAC framework is compiled in or not. -Steve -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
