Gerke M. Preussner | 20 Sep 11:48 2015

(kein Betreff)

Simon Maurer | 20 Jun 19:49 2015

selinux + systemd

I tried to use selinux with systemd, but without much success. Looks
like the whole transitioning is broken. (Most daemons are stuck in the
init_t domain) What I don't understand is, while more and more disros
switching to systemd, it seems like there is still no working selinux
policy with systemd support. So how do other distros support selinux?

While I'm tying to figure this selinux thingy out, a few questions came
to mind:
Most packages with the selinux use flag are just pulling their reference
policy module as a dependency. Wouldn't it be better to use the seinux
flag only for packages which are linked against libselinux and use
instead a SELINUX_MODULES variable in the make.conf file (similar to

The tresys reference policy uses the distro_gentoo directive, but AFAIK
it only affects openrc stuff. So shouldn't it be renamed to init_openrc?

Best regards,

eduardo lenz | 15 Jul 07:19 2014

Resposta automática

This account is not active. Please send e-mails to lenz <at>

cfp | 15 Jul 07:16 2014

Ruxcon 2014 Final Call For Presentations

______________________________________________________________ _._) (_._ | .%$$% .. | ' __________. ._____ ________.&&$ '$$%$.__________ ' ._\ /___.___\ \_____/ ____/$ &&$\ /_ -:-\ \_____\ | /____/ /________\'$#%. .$&&'/____/ /-:- /____/ \________/ \____\ ' %$$$%' /_____/ . . _|_ _|_ '(______________________________________________________________)'

The Ruxcon team is pleased to announce the Final Call For Presentations for Ruxcon 2014.

This year the conference will take place over the weekend of the 11th and 12th of October at the CQ Function Centre, Melbourne, Australia.

The deadline for submissions is the 15th of September, 2014.

About Ruxcon

Ruxcon is the premier technical computer security conference in Australia. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

Important Dates

  • September 15 - Call For Presentations Close
  • October 6-7 - Ruxcon/Breakpoint Training
  • October 8-9 - Breakpoint Conference
  • October 11-12 - Ruxcon Conference

Topic Scope

Topics of interest include, but are not limited to:

  • Mobile Device Security
  • Virtualization, Hypervisor, and Cloud Security
  • Malware Analysis
  • Reverse Engineering
  • Exploitation Techniques
  • Rootkit Development
  • Code Analysis
  • Forensics and Anti-Forensics
  • Embedded Device Security
  • Web Application Security
  • Network Traffic Analysis
  • Wireless Network Security
  • Cryptography and Cryptanalysis
  • Social Engineering
  • Law Enforcement Activities
  • Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)
Submission Guidelines

In order for us to process your submission we require the following information:

1. Presentation title
2. Detailed summary of your presentation material
3. Name/Nickname
4. Mobile phone number
5. Brief personal biography
6. Description of any demonstrations involved in the presentation
7. Information on where the presentation material has or will be presented before Ruxcon

As a general guideline, Ruxcon presentations are between 45 and 60 minutes, including question time.

Please note that Ruxcon isn't able to cover any travel expenses for speakers. Speakers in the past have had success in having their employer cover conference related expenses. Our other conference Breakpoint does cover travel expenses and runs 3 days before Ruxcon.

If you have any enquiries about submissions, or would like to make a submission, please send an email to presentations <at>

cfp | 7 May 02:34 2014

Breakpoint 2014 Call For Presentations

Breakpoint 2014 Call For Papers
Melbourne, Australia, October 8th-9th
Intercontinental Rialto

.[x]. Introduction .[x].

 The Ruxcon team is pleased to announce Call For Papers for Breakpoint 2014.

 Breakpoint showcases the work of expert security researchers from around the
 world on a wide range of topics. This conference is organised by the Ruxcon 
 team and offers a specialised security conference to complement and lead into 
 the larger and more casual Ruxcon weekend conference. 

.[x]. Important Dates .[x].

 May 1 - Call For Presentations Open
 August 30 - Call For Presentations Close
 October 6-7 - Breakpoint Training
 October 8-9 - Breakpoint Conference
 October 11-12 - Ruxcon Conference

.[x]. Topic Scope .[x].

Topics of interest include, but are not limited to:

 o Mobile Device Security
 o Exploitation Techniques
 o Reverse Engineering
 o Vulnerability Discovery
 o Rootkit Development
 o Malware Analysis
 o Code Analysis
 o Virtualisation, Hypervisor Security
 o Cloud Security
 o Embedded Device Security
 o Hardware Security
 o Telecommunications Security
 o Wireless Network Security
 o Web Application Security
 o Law Enforcement Activities
 o Forensics
 o Threat Intelligence

.[x]. Submission Guidelines .[x].

 In order for us to process your submission we will require the following 

 1. Presentation title
 2. Detailed summary of your presentation material
 3. Name/Nickname
 4. Mobile phone number
 5. Brief personal biography
 6. Description of any demonstrations involved in presentation
 7. Information on where the presentation material has or will be presented 
    before Breakpoint

 * Preference will be given to presentations that contain original research 
   that will be first presented at Breakpoint. 
 * As a general guideline, Breakpoint presentations are between 
   45 and 60 minutes, including question time. 

 If you have any questions about submissions, or would like to make a 
 submission, please send an email to submissions <at>

.[x]. Speaker Benefits .[x].

 Speakers at Breakpoint will be entitled to the following benefits:                                                

 - A return economy airfare to Melbourne (total cost limit applies)
 - Three nights accommodation at the Intercontinental Rialto
 - Complimentary registration for Breakpoint and Ruxcon conferences
 - Invitation to all Breakpoint and Ruxcon parties

 * All speaker benefits apply to a single speaker per submission. 

.[x]. Contact .[x]. 

 If you have any questions or inqueries, contact us at:

 * Email:	submissions <at>
 * Twitter:	 <at> ruxconbpx

Jo | 9 Apr 18:39 2014

Regeneration of gpg keys after HeartBleed

Hi all, this is my first post in this list, so again Hi all!

I'm a bit concerned about the signing keys of the portage tree releases,
I know that gpg is not the same as openssl but keeping in mind that SSH,
VPN, HTTPS keys might be compromised for two years, don't you think it's
a healthy measure to generate a new pair of keys?

Thank you

Samuel Damashek | 18 Jan 05:25 2014

glksa-check Proof of Concept

At the request of creffett, I created a Proof of Concept for
glksa-check, which allows for glksa XML files to define Kernel
security vulnerabilities. Please realize that this is a Proof of
Concept, and that the interface is not the most user-friendly. The
code can definitely be improved as well. To test the program, untar
the files and copy the glksa dir to /usr/portage/metadata/. At the
moment, the script requires you to have /proc/config.gz enabled in
your kernel to read your running config options.

I have two XML files currently defined (still using the glsa.dtd
schema); one that is an actual vulnerability and one that is simply a
control that triggers on X86. To test the program, run it with the -l

You can download the files at
(not sure if the mailing lists let you attach tarballs). There is
definitely a lot to be improved about the application; this is just an
idea for how to handle notifying users about Kernel vulnerabilities
that affect their system. They would be released just like glsas. What
are the list's opinions on this?

Samuel Damashek
Sascha Wolf | 10 Jan 16:02 2014

Soliciting feedback for the GLSA-2 format


I  find  the  new  version of GLSA format very interesting, especially
with the backdrop of the automated evaluation of vulnerabilities.

Would  it  be  possible  to  specify  in  which branch of Gentoo, this
program is usually installed? For example, "stable" or "unstable"?

So you can better see if you are actively involved or not.


Best regards,
 Sascha Wolf
Attachment (smime.p7s): application/pkcs7-signature, 7827 bytes
Samuel Damashek | 8 Jan 03:28 2014

Re: Kernel Vulnerability Handling and Classification Criteria


> Hello Samuel, are security vulnerabilities not classified by
> in a way that can be simply and consistently
> leveraged? I wouldn't expect gentoo to implement kernel patches
> before the Linux kernel maintainers blessed the patch, and I'd
> imagine that a cve number would have been assigned by then, our am
> I  mistaken?
Yes, CVE's are assigned to kernel vulnerabilities, and I'm thinking
that in general, these criteria would be applied after they are
assigned a CVE (although that's not a requirement of course). We have
our own criteria for Portage packages because it can take time before
the issues are classified by MITRE, and the classifications aren't
Gentoo specific (correct me if I'm wrong here).

Samuel Damashek | 8 Jan 03:04 2014

Kernel Vulnerability Handling and Classification Criteria

At the moment, we don't have an accepted and documented way to handle
Kernel CVEs. Right now, they're just being filed and then maybe being
resolved when upstream commits a patch.

I believe we need some way of judging priority and severity of kernel
vulnerabilities to improve bug handling and make sure that we stay
up-to-date with current patches being released. Linux kernel
development is very fast paced, so we should set up a clear system,
much like we have right now for packages in Portage, to facilitate the
filing and management of these bugs.

I'm not really a kernel guy, but there are some things that I can
figure out and propose without knowing much about kernel internals.
First, we could classify priority (giving it a letter grade) by
considering whether the issue is in kernel code that is enabled by
default, or whether the user has to enable the vulnerable code in the
kernel config. We could also use the tilde (~) as a grade when the
vulnerable code is marked EXPERIMENTAL in the config, much like we do
for unstable packages.

As far as severity goes, I think that severity would be similar to
what we have at the moment for packages, with maybe some minor
improvements to make the descriptions relevant. Priority and severity
could then be translated to an appropriate Whiteboard grade for better

We need to develop and agree on solid criteria so that bug wranglers
can classify security issues efficiently.

Since the general workflow for handling kernel issues is report to
upstream -> patch -> patch included in next release, we can have three
statuses in the Whiteboard field to represent these. Just as a
proposal, those could be "upstream" and "patch", and then close the
bug as Resolved Fixed when the next version is released. An
alternative is to close the bug when the patch is committed to the
kernel repositories instead of when the next version is released.

Something else to consider is whether GLSAs will be released after a
release is available. I have varying opinions on the matter, as while
the Kernel is not a part of Gentoo persay, it is still a security
issue that should be reported to users and spread for wide
distribution. I'm open to opinions on this matter.

Samuel Damashek
Alex Legler | 8 Jan 02:14 2014

Soliciting feedback for the GLSA-2 format

Now that we've been growing a bit in numbers and have managed to get the
GLSA circulation back on track, it is time to finally talk about the new
GLSA format that has been planned for quite a while.
The main goal of the new format is to support slots which is a feature
especially glsa-check users will welcome. [1]
Besides, it has become clear that filling in information in the level of
detail the current format provides takes too much time while  drafting

Tobias and I took a bit of time today to combine all desired changes
into a new sample document:

Quick outline of the most important changes:

- Synopsis removed: The title provides a quick overview of the issues,
while the new shorter description provides details, yet briefly as well.
People requiring even more information can use the linked CVE entries,
bugs, and other references.

- Product and GLSA type removed: There are only 'ebuild' type GLSAs
issued, the other types are no longer needed. Product was linked to that.

- Packages section reworked: While adding Slot support we tried to get a
new, simple, range-based scheme for marking vulnerable versions. The
flexibility the range operators offered before was hardly ever used
(mostly just to work around the lacking Slot support). We'd especially
like feedback in this area, I fear we might be missing some
functionality here. Quick explanation:
 <package name="dev-lang/python">
   <vulnerable slot="3.2" fixed="3.2.9"/>
   <vulnerable slot="3.3" asof="3.3.0" fixed="3.3.1"/>
   <vulnerable slot="3.3" asof="3.3.3" fixed="3.3.5"/>
   <vulnerable slot="0" fixed="6.3"/>
 <package name="dev-lang/python" arch="hppa">

Reads as follows:
On hppa, there is no fixed version.
On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected
for anything less, in the 3.3 slot, [3.3.0; 3.3.1[ and [3.3.3; 3.3.5[
are affected, for the 0 slot, anything <6.3 is affected.

- Human-readable texts reworked: Background + Description + Resolution
instead of (Synopsis) + Background + Description + Impact + Resolution.

- References reworked: Bugs moved into that tag, CVEs get their own tag
without a link that could break, other references go as <url>

- Metadata: Mostly leftovers from GLSAMaker v1 removed; We now list the
author as well as people reviewing a draft and signing off on it with a
proper name. Dates are in a standardized format.

If there are any other questions, we'll do our best to answer them.
Other than that, we'd appreciate any feedback.

[1] Especially after today most glsa-check users got another set of
false-positives from a faulty python GLSA that could have used it.


Alex Legler <a3li <at>>
Gentoo Security/Ruby/Infrastructure