[ANNOUNCE] Linux Security Summit 2017 - CFP

2017-03-23 Thread James Morris 

==
   ANNOUNCEMENT AND CALL FOR PARTICIPATION

  LINUX SECURITY SUMMIT 2017
 
   14-15 September
   LOS ANGELES, USA
==


DESCRIPTION

  The Linux Security Summit (LSS) is a technical forum for collaboration
  between Linux developers, researchers, and end users. Its primary aim is to
  foster community efforts in analyzing and solving Linux security challenges.

  LSS this year will be co-located with the Open Source Summit and the Linux
  Plumbers Conference.

  The program committee currently seeks proposals for:

* Refereed Presentations:
  45 minutes in length, including at least 10 minutes of discussion.

* Discussion Topics:
  30 minutes in length.

  Topic areas include, but are not limited to:

* Kernel self-protection
* Access control
* Cryptography and key management
* Integrity control
* Hardware Security
* Iot and embedded security
* Virtualization and containers
* System-specific system hardening
* Case studies
* Security tools
* Security UX
* Emerging technologies, threats & techniques 

  Proposals should be submitted via:
http://events.linuxfoundation.org/events/linux-security-summit/program/cfp


DATES

  * CFP Close: June 5, 2017
  * CFP Notifications: June 12, 2017
  * Schedule Announced: June 19, 2017
  * Slide Submission: August 31, 2017


WHO SHOULD ATTEND

  We're seeking a diverse range of attendees, and welcome participation by
  people involved in Linux security development, operations, and research.

  The LSS is a unique global event which provides the opportunity to present
  and discuss your work or research with key Linux security community members
  and maintainers.  It’s also useful for those who wish to keep up with the
  latest in Linux security development, and to provide input to the
  development process.


WEB SITE

  http://events.linuxfoundation.org/events/linux-security-summit


TWITTER

  For event updates and announcements, follow:

https://twitter.com/LinuxSecSummit
  

PROGRAM COMMITTEE

  The program committee for LSS 2017 is:

* James Morris, Oracle
* Serge Hallyn, Canonical
* Paul Moore, Red Hat
* Stephen Smalley, NSA
* Elena Reshetova, Intel
* John Johansen, Canonical
* Kees Cook, Google
* Casey Schaufler, Intel
* Mimi Zohar, IBM
* David A. Wheeler, Institute for Defense Analyses

  The program committee may be contacted as a group via email:
lss-pc () lists.linuxfoundation.org--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH V4 2/2] audit: normalize NETFILTER_PKT

2017-03-23 Thread Paul Moore 
On Wed, Mar 22, 2017 at 3:05 AM, Richard Guy Briggs  wrote:
> Eliminate flipping in and out of message fields, dropping fields in the
> process.
>
> Sample raw message format IPv4 UDP:
> type=NETFILTER_PKT msg=audit(1487874761.386:228):  mark=0xae8a2732 
> saddr=127.0.0.1 daddr=127.0.0.1 proto=17^]
> Sample raw message format IPv6 ICMP6:
> type=NETFILTER_PKT msg=audit(1487874761.381:227):  mark=0x223894b7 saddr=::1 
> daddr=::1 proto=58^]
>
> Issue: https://github.com/linux-audit/audit-kernel/issues/11
> Test case: https://github.com/linux-audit/audit-testsuite/issues/43
>
> Signed-off-by: Richard Guy Briggs 
> ---
> v4:
> Write out nfmark unmodified rather than trying to indicate "unset".
> Collapse/simplify switch/case statements.
> v3:
> Don't store interim values, but print immediately.
> v2:
> Trim down to 4 fields.  Add raw samples.
>
>  net/netfilter/xt_AUDIT.c |  124 
> ++
>  1 files changed, 27 insertions(+), 97 deletions(-)

Looks good, merged to audit/next.

> diff --git a/net/netfilter/xt_AUDIT.c b/net/netfilter/xt_AUDIT.c
> index cdb7cee..582ee54 100644
> --- a/net/netfilter/xt_AUDIT.c
> +++ b/net/netfilter/xt_AUDIT.c
> @@ -31,146 +31,76 @@ MODULE_ALIAS("ip6t_AUDIT");
>  MODULE_ALIAS("ebt_AUDIT");
>  MODULE_ALIAS("arpt_AUDIT");
>
> -static void audit_proto(struct audit_buffer *ab, struct sk_buff *skb,
> -   unsigned int proto, unsigned int offset)
> -{
> -   switch (proto) {
> -   case IPPROTO_TCP:
> -   case IPPROTO_UDP:
> -   case IPPROTO_UDPLITE: {
> -   const __be16 *pptr;
> -   __be16 _ports[2];
> -
> -   pptr = skb_header_pointer(skb, offset, sizeof(_ports), 
> _ports);
> -   if (pptr == NULL) {
> -   audit_log_format(ab, " truncated=1");
> -   return;
> -   }
> -
> -   audit_log_format(ab, " sport=%hu dport=%hu",
> -ntohs(pptr[0]), ntohs(pptr[1]));
> -   }
> -   break;
> -
> -   case IPPROTO_ICMP:
> -   case IPPROTO_ICMPV6: {
> -   const u8 *iptr;
> -   u8 _ih[2];
> -
> -   iptr = skb_header_pointer(skb, offset, sizeof(_ih), &_ih);
> -   if (iptr == NULL) {
> -   audit_log_format(ab, " truncated=1");
> -   return;
> -   }
> -
> -   audit_log_format(ab, " icmptype=%hhu icmpcode=%hhu",
> -iptr[0], iptr[1]);
> -
> -   }
> -   break;
> -   }
> -}
> -
> -static void audit_ip4(struct audit_buffer *ab, struct sk_buff *skb)
> +static bool audit_ip4(struct audit_buffer *ab, struct sk_buff *skb)
>  {
> struct iphdr _iph;
> const struct iphdr *ih;
>
> ih = skb_header_pointer(skb, skb_network_offset(skb), sizeof(_iph), 
> &_iph);
> -   if (!ih) {
> -   audit_log_format(ab, " truncated=1");
> -   return;
> -   }
> +   if (!ih)
> +   return false;
>
> -   audit_log_format(ab, " saddr=%pI4 daddr=%pI4 ipid=%hu proto=%hhu",
> -   &ih->saddr, &ih->daddr, ntohs(ih->id), ih->protocol);
> +   audit_log_format(ab, " saddr=%pI4 daddr=%pI4 proto=%hhu",
> +&ih->saddr, &ih->daddr, ih->protocol);
>
> -   if (ntohs(ih->frag_off) & IP_OFFSET) {
> -   audit_log_format(ab, " frag=1");
> -   return;
> -   }
> -
> -   audit_proto(ab, skb, ih->protocol, ih->ihl * 4);
> +   return true;
>  }
>
> -static void audit_ip6(struct audit_buffer *ab, struct sk_buff *skb)
> +static bool audit_ip6(struct audit_buffer *ab, struct sk_buff *skb)
>  {
> struct ipv6hdr _ip6h;
> const struct ipv6hdr *ih;
> u8 nexthdr;
> __be16 frag_off;
> -   int offset;
>
> ih = skb_header_pointer(skb, skb_network_offset(skb), sizeof(_ip6h), 
> &_ip6h);
> -   if (!ih) {
> -   audit_log_format(ab, " truncated=1");
> -   return;
> -   }
> +   if (!ih)
> +   return false;
>
> nexthdr = ih->nexthdr;
> -   offset = ipv6_skip_exthdr(skb, skb_network_offset(skb) + 
> sizeof(_ip6h),
> - &nexthdr, &frag_off);
> +   ipv6_skip_exthdr(skb, skb_network_offset(skb) + sizeof(_ip6h), 
> &nexthdr, &frag_off);
>
> audit_log_format(ab, " saddr=%pI6c daddr=%pI6c proto=%hhu",
>  &ih->saddr, &ih->daddr, nexthdr);
>
> -   if (offset)
> -   audit_proto(ab, skb, nexthdr, offset);
> +   return true;
>  }
>
>  static unsigned int
>  audit_tg(struct sk_buff *skb, const struct xt_action_param *par)
>  {
> -   const struct xt_audit_info *info = par->targinfo;
> struct audit_buffer *ab;
> +   int fam = -1;
>
> if (audit_enabled == 0)
> goto errout;
>

Re: [PATCH V4 1/2] netfilter: xt_AUDIT: use consistent ipv4 network offset

2017-03-23 Thread Paul Moore 
On Wed, Mar 22, 2017 at 7:43 AM, Richard Guy Briggs  wrote:
> On 2017-03-22 12:11, Pablo Neira Ayuso wrote:
>> On Wed, Mar 22, 2017 at 03:05:36AM -0400, Richard Guy Briggs wrote:
>> > Even though the skb->data pointer has been moved from the link layer
>> > header to the network layer header, use the same method to calculate the
>> > offset in ipv4 and ipv6 routines.
>> >
>> > Signed-off-by: Richard Guy Briggs 
>> > ---
>> >  net/netfilter/xt_AUDIT.c |2 +-
>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/net/netfilter/xt_AUDIT.c b/net/netfilter/xt_AUDIT.c
>> > index 4973cbd..cdb7cee 100644
>> > --- a/net/netfilter/xt_AUDIT.c
>> > +++ b/net/netfilter/xt_AUDIT.c
>> > @@ -76,7 +76,7 @@ static void audit_ip4(struct audit_buffer *ab, struct 
>> > sk_buff *skb)
>> > struct iphdr _iph;
>> > const struct iphdr *ih;
>> >
>> > -   ih = skb_header_pointer(skb, 0, sizeof(_iph), &_iph);
>> > +   ih = skb_header_pointer(skb, skb_network_offset(skb), sizeof(_iph), 
>> > &_iph);
>>
>> This update is completely pointless.
>
> Its point is to be consistent with audit_ip6() and to prevent further
> time consumed by confusion and head-scratching.  I know it is slightly
> slower with an identical result.

Agree with Richard, merged to audit/next.

-- 
paul moore
www.paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: auditd.cron

2017-03-23 Thread Steve Grubb 
On Thursday, March 23, 2017 9:53:45 AM EDT Simon Sekidde wrote:
> - Original Message -
> 
> > From: "Ed Christiansen MS" 
> > To: linux-audit@redhat.com
> > Sent: Thursday, March 23, 2017 9:28:34 AM
> > Subject: Re: auditd.cron
> > 
> > So, if I read this right, to implement an auditd log rotation that is
> > based on time one would:
> > 
> > 1. set num_logs to 0 in auditd.conf
> 
> This implies no rotation

Which is exactly what you want because the only setting checked to see if its 
time to rotate is the max_log_file setting.

> > 2. send SIGUSR1 to auditd based on your log rotation schedule.
>
> `service auditd rotate` will force a rotation

Yes, but it can be scripted without needing to use service if desired.

> > Are there any other nuances I need to take into consideration?

You might set max_log_file_action to ignore to avoid any syslog warnings. By 
using the SIGUSR1 method the logs will have a number appended to them and the 
audit utilities can still make sense of the order of log files.

If you choose to rename the files, then you will also need to make a script 
that understands the order and cats them into ausearch/report in the correct 
order if you still plan to use the native tools.

-Steve

> > On 3/22/2017 5:48 PM, Steve Grubb wrote:
> > > On Wednesday, March 22, 2017 5:19:11 PM EDT warron.french wrote:
> > >> So, I needed a feature over 8 months ago, nobody could provide one for
> > >> the
> > >> 
> > >> following:
> > >>Rolling log files either when they hit a certain size or the day
> > >> 
> > >> changed over at midnight.
> > >> 
> > >> I know that I could have rolled the files at a specific size, by using
> > >> the
> > >> *max_log_file* attribute as identified in the */etc/audit/auditd.conf*,
> > >> but
> > >> there was no "builtin" for managing auto rotation at the start of a new
> > >> day
> > >> ( hrs).
> > >> 
> > >> It looks like there is a file called
> > >> */usr/share/doc/auditd-<**version>*
> > >> */auditd.cron*
> > >> 
> > >> *.*
> > >> To me*, *this file is new; considering I needed it 8 months ago.
> > > 
> > > Its over 9 years old.
> > > 
> > >> *Anyway, how is this file implemented?
> > > 
> > > https://github.com/linux-audit/audit-userspace/blob/master/init.d/auditd
> > > .cron
> > > 
> > > Its a shell script that end up sending SIGUSR1 to auditd. That causes
> > > auditd
> > > to rotate the files. But you would also configure auditd to not rotate
> > > files by
> > > setting num_logs to 0 in auditd.conf.
> > > 
> > >> * Simply move it to a directory with permissions to execute; ensure it
> > >> is
> > >> executable and then simply set up a cronjob to execute it at whatever
> > >> time
> > >> of day that I wish?
> > > 
> > > Yes. You can also extend the script by sleeping a couple seconds for the
> > > rotation and then rename the file and/or compress it and/or move it to
> > > another
> > > directory or partition. Whatever you want to do.
> > > 
> > >> *Finally, if I have '-e 2' as the last control in the audit.rules file;
> > >> will the auditd.cron which executes as service auditd rotate still
> > >> function
> > >> properly?*
> > > 
> > > The -e 2 makes the rules immutable. Sending SIGUSR1 to the audit daemon
> > > just
> > > rotates the files. So, it has no bearing on the matter.
> > > 
> > > -Steve
> > > 
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: auditd.cron

2017-03-23 Thread Ryan Sawhill 
On Wed, Mar 22, 2017 at 5:19 PM, warron.french 
wrote:

> So, I needed a feature over 8 months ago, nobody could provide one for the
> following:
>Rolling log files either when they hit a certain size or the day
> changed over at midnight.
>
> I know that I could have rolled the files at a specific size, by using the
> *max_log_file* attribute as identified in the */etc/audit/auditd.conf*,
> but there was no "builtin" for managing auto rotation at the start of a new
> day ( hrs).
>
> It looks like there is a file called */usr/share/doc/auditd-<**version>*
> */auditd.cron*
>
> *.*
> To me*, *this file is new; considering I needed it 8 months ago.
>
> *Anyway, how is this file implemented? * Simply move it to a directory
> with permissions to execute; ensure it is executable and then simply set up
> a cronjob to execute it at whatever time of day that I wish?
>
> *Finally, if I have '-e 2' as the last control in the audit.rules file;
> will the auditd.cron which executes as service auditd rotate still function
> properly?*
>


Steve covered the important parts, but for more hand-holding:

How to implement audit log rotation with compression based on time instead
of size 
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: auditd.cron

2017-03-23 Thread Simon Sekidde 


- Original Message -
> From: "Ed Christiansen MS" 
> To: linux-audit@redhat.com
> Sent: Thursday, March 23, 2017 9:28:34 AM
> Subject: Re: auditd.cron
> 
> So, if I read this right, to implement an auditd log rotation that is
> based on time one would:
> 
> 1. set num_logs to 0 in auditd.conf
> 
This implies no rotation

> 2. send SIGUSR1 to auditd based on your log rotation schedule.
> 
> Are there any other nuances I need to take into consideration?
> 

`service auditd rotate` will force a rotation

> On 3/22/2017 5:48 PM, Steve Grubb wrote:
> > On Wednesday, March 22, 2017 5:19:11 PM EDT warron.french wrote:
> >> So, I needed a feature over 8 months ago, nobody could provide one for the
> >> following:
> >>Rolling log files either when they hit a certain size or the day
> >> changed over at midnight.
> >>
> >> I know that I could have rolled the files at a specific size, by using the
> >> *max_log_file* attribute as identified in the */etc/audit/auditd.conf*,
> >> but
> >> there was no "builtin" for managing auto rotation at the start of a new
> >> day
> >> ( hrs).
> >>
> >> It looks like there is a file called */usr/share/doc/auditd-<**version>*
> >> */auditd.cron*
> >>
> >> *.*
> >> To me*, *this file is new; considering I needed it 8 months ago.
> >
> > Its over 9 years old.
> >
> >> *Anyway, how is this file implemented?
> >
> > https://github.com/linux-audit/audit-userspace/blob/master/init.d/auditd.cron
> >
> > Its a shell script that end up sending SIGUSR1 to auditd. That causes
> > auditd
> > to rotate the files. But you would also configure auditd to not rotate
> > files by
> > setting num_logs to 0 in auditd.conf.
> >
> >> * Simply move it to a directory with permissions to execute; ensure it is
> >> executable and then simply set up a cronjob to execute it at whatever time
> >> of day that I wish?
> >
> > Yes. You can also extend the script by sleeping a couple seconds for the
> > rotation and then rename the file and/or compress it and/or move it to
> > another
> > directory or partition. Whatever you want to do.
> >
> >> *Finally, if I have '-e 2' as the last control in the audit.rules file;
> >> will the auditd.cron which executes as service auditd rotate still
> >> function
> >> properly?*
> >
> > The -e 2 makes the rules immutable. Sending SIGUSR1 to the audit daemon
> > just
> > rotates the files. So, it has no bearing on the matter.
> >
> > -Steve
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

-- 
Simon Sekidde * Red Hat, Inc. * Tyson's Corner, VA
Solution Architect, NA Public Sector


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: auditd.cron

2017-03-23 Thread Ed Christiansen MS 
So, if I read this right, to implement an auditd log rotation that is 
based on time one would:


1. set num_logs to 0 in auditd.conf

2. send SIGUSR1 to auditd based on your log rotation schedule.

Are there any other nuances I need to take into consideration?

On 3/22/2017 5:48 PM, Steve Grubb wrote:

On Wednesday, March 22, 2017 5:19:11 PM EDT warron.french wrote:

So, I needed a feature over 8 months ago, nobody could provide one for the
following:
   Rolling log files either when they hit a certain size or the day
changed over at midnight.

I know that I could have rolled the files at a specific size, by using the
*max_log_file* attribute as identified in the */etc/audit/auditd.conf*, but
there was no "builtin" for managing auto rotation at the start of a new day
( hrs).

It looks like there is a file called */usr/share/doc/auditd-<**version>*
*/auditd.cron*

*.*
To me*, *this file is new; considering I needed it 8 months ago.


Its over 9 years old.


*Anyway, how is this file implemented?


https://github.com/linux-audit/audit-userspace/blob/master/init.d/auditd.cron

Its a shell script that end up sending SIGUSR1 to auditd. That causes auditd
to rotate the files. But you would also configure auditd to not rotate files by
setting num_logs to 0 in auditd.conf.


* Simply move it to a directory with permissions to execute; ensure it is
executable and then simply set up a cronjob to execute it at whatever time
of day that I wish?


Yes. You can also extend the script by sleeping a couple seconds for the
rotation and then rename the file and/or compress it and/or move it to another
directory or partition. Whatever you want to do.


*Finally, if I have '-e 2' as the last control in the audit.rules file;
will the auditd.cron which executes as service auditd rotate still function
properly?*


The -e 2 makes the rules immutable. Sending SIGUSR1 to the audit daemon just
rotates the files. So, it has no bearing on the matter.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit





smime.p7s
Description: S/MIME Cryptographic Signature
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit