The 2016 Linux Security Summit CFP

As was posted to various mailing lists last week, the Linux Security Summit Call for Participation:

ANNOUNCEMENT AND CALL FOR PARTICIPATION

LINUX SECURITY SUMMIT 2016
25-26 AUGUST
TORONTO, CANADA

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.

The format of the summit will be:

• Refereed presentations
• Discussion topics
• Subsystem reports
• Breakout development sessions

WEB SITE

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

TWITTER

For event updates and announcements, follow: @LinuxSecSummit

DATES / LOCATION

The Linux Security Summit for 2016 will be held August 25th and 26th in Toronto, Canada. It will be co-located with LinuxCon.

The Linux Security Summit CFP is now open, and will close on June 10th.

Accepted speakers will be notified by June 17th.

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.

CALL FOR PARTICIPATION

The program committee currently seeks proposals for:

• Refereed Presentations: 45 minutes in length, including at least 10 minutes of discussion. One-page abstracts are encouraged.

• 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
• Trust systems
• Storage and file systems
• Virtualization and containers
• Case studies
• Identity management
• Code analysis
• Security analytics
• Secure development and operational practices
• Emerging technologies, threats & techniques

Proposals should be submitted via the event web site:

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

PROGRAM COMMITTEE

The Linux Security Summit for 2016 is organized by:

• James Morris, Oracle
• Serge Hallyn, Canonical
• Paul Moore, Red Hat
• Stephen Smalley, NSA
• Elena Reshetova, Intel
• Herbert Xu, Red Hat
• John Johansen, Canonical
• Kees Cook, Google
• Casey Schaufler, Intel
• Mimi Zohar, IBM

The program committee may be contacted as a group via email:

lss-pc@lists.linuxfoundation.org

Linux 4.5 Released

Linux 4.5 was released this past weekend, here are the SELinux and audit release notes.

SELinux

• New LSM hooks and SELinux code to invalidate and revalidate inode security labels. This is important functionality for GFS2 and potentially other distributed filesystems.

• New functionality to make the validatetrans policy decisions available to userspace via the selinuxfs mount, “/sys/fs/selinux” on most systems. Writing “$oldcontext $newcontext $tclass $taskcontext” to “/sys/fs/selinux/validatetrans” will return 0 if the transition is allowed and -EPERM otherwise.

Audit

• A number of small improvements were made to help make the kernel/auditd connection more robust and fix some corner cases relating to audit queue backlog handling.

• Auditing of seccomp events now honors the “audit_enabled” flag; when “audit_enabled=0” then seccomp events will not be audited.

• Make selection of CONFIG_AUDITSYSCALL automatic on systems that have auditing enabled and support syscall auditing.

Kernel Repository Process

Update: new process defined here

Just as the software changes over time to better serve our needs, so should our processes. Starting with the upcoming merge window, I’m changing the process used to manage the SELinux and audit repositories. The new approach is described below:

1. When it is time to send a pull request upstream (approximately one or two RC releases before the merge window for SELinux, during the merge window for audit), copy the next branch of the repository to a new branch, stable-X.YY, such that X.YY matches the version of the upcoming release. Send the pull request using the new stable-X.YY branch.

2. Rebase the next branch:
   • In the case of SELinux, rebase the next branch against the linux-security/next branch. It tends to be common practice for the linux-security/next branch to be rebased on a semi-regular basis against Linus’ X.YY-rc1 or X.YY-rc2 release, as a result the SELinux next branch may need to be rebased outside the regular merge window cycle.
   • In the case of audit, rebase the next branch against Linus’ latest stable release, the kernel release that started the merge window.
3. Accept patches into the stable-X.YY and next branches as appropriate during the development cycle. Send stable-X.YY patches upstream as soon as they have been reviewed and verified against the appropriate test suites. Continue until it is time to send the next pull request upstream.

For reference, the old process was defined here.