-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 04:00 PM, Arthur Țițeică wrote:
My conclusions so far: there's no difference between the stock -ARCH kernel
and my -NOLSM build in which I disabled all LSMs (and hence audit).
Note: the final test with 50 files for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2014 09:45 AM, Arthur Țițeică wrote:
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris:
I want to trim our kernel down to what we actually support.
1) Once we agreed to disable one LSM, everyone else said we can
The audit support required by these can't be compiled in without it
being enabled. It's useless crap for anyone who isn't working for a
bureaucracy and it spams the logs. It is also completely broken with
namespaces, so it doesn't work at all with containers or application
sandboxes.
If and when
Hi,
În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
And here is my problem: Audit is enabled by default and must be
explicitly disabled by the admin. This is a showstopper for me! There is
no kernel option to configure audit to be disabled by default (as far as
I am aware)
On Fri, Mar 28, 2014 at 11:54 AM, Arthur Țițeică art...@psw.ro wrote:
Hi,
În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
And here is my problem: Audit is enabled by default and must be
explicitly disabled by the admin. This is a showstopper for me! There is
no kernel
On 28-03-2014 10:54, Arthur Țițeică wrote:
It raises a question mark that the two most important components of a system
(systemd and the kernel) have security measures disabled.
People in this thread like to put out the over subjective lightweight
factor
but still there are no bug
On 28/03/14 06:54 AM, Arthur Țițeică wrote:
Hi,
În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
And here is my problem: Audit is enabled by default and must be
explicitly disabled by the admin. This is a showstopper for me! There is
no kernel option to configure audit to
On Fri, Mar 28, 2014 at 12:54:44PM +0200, Arthur Țițeică wrote:
It raises a question mark that the two most important components of a system
(systemd and the kernel) have security measures disabled.
People in this thread like to put out the over subjective lightweight
factor
but still
I'll answer random things I read in the thread. First, I don't think the
lightweight part of the philosophy is about using stock packages, as
that's implied in the KISS philosophy, you don't need to stress it any more
than that. The same KISS philosophy says one should try to avoid complexity
On Fri, Mar 28, 2014 at 2:40 PM, Bigby James bigby.ja...@crepcran.com wrote:
On Fri, Mar 28, 2014 at 12:01:06PM +0100, Martti Kühne wrote:
I'm very much for cleaning up the kernel config from things that
factually are useless.
Factually useless is not a subjective standard by which to
On Fri, Mar 28, 2014 at 03:05:25PM +0100, Martti Kühne wrote:
Well, they came in when people argued in favor of them. [0]
[0]
https://mailman.archlinux.org/pipermail/arch-general/2013-November/034385.html
That entire thread regards the userspace packages and the kludge of a policy
that are
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@crepcran.com wrote:
So you think it's justifiable to expect someone you don't know to spend more
time than necessary performing a tedious and monotonous task, because maybe,
someday, it might make your life slightly more convenient? What
On Fri, Mar 28, 2014 at 12:01:06PM +0100, Martti Kühne wrote:
I'm very much for cleaning up the kernel config from things that
factually are useless.
Factually useless is not a subjective standard by which to measure things. If
you don't personally configure the features in question by
On 03/28/2014 09:12 AM, Daniel Micay wrote:
...
Security needs to be simple, predictable and well understood. It needs
to be provably correct and easily audited. SELinux is none of these
things. I don't really understand why a distribution striving for
simplicity would ever enable it.
I
Am 28.03.2014 17:11, schrieb Martti Kühne:
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@crepcran.com wrote:
So you think it's justifiable to expect someone you don't know to spend more
time than necessary performing a tedious and monotonous task, because maybe,
someday, it might
Hi,
În ziua de Vineri 28 Martie 2014, la 12:54:44, Arthur Țițeică a scris:
As a side note I will try to test the worst case scenario in the Phoronix
tests -- Postmark, and post the results here.
I managed to finish testing.
As said above I picked up this test because it was the only one
On 28/03/14 02:36 PM, Genes Lists wrote:
On 03/28/2014 09:12 AM, Daniel Micay wrote:
...
Security needs to be simple, predictable and well understood. It needs
to be provably correct and easily audited. SELinux is none of these
things. I don't really understand why a distribution striving
Hello,
2014-03-26 20:18 GMT+01:00 Leonid Isaev lis...@umail.iu.edu:
On Wed, 26 Mar 2014 19:56:26 +0100
Thomas Bächler tho...@archlinux.org wrote:
Hello all,
it won't be too long until 3.14 is out and I want to address a topic
that has been bugging me for a while. Our kernel includes
I think what Nicolas says is a good idea. I realise that Arch is not really
a security-focused distro, but having to not recompile the kernel on my
laptop after every upgrade with SELinux enabled is a pretty awesome thing.
I realise that this is not really relevant to most Archers, but with Siosm
On Thursday 27 Mar 2014 09:07:23 Nicolas Iooss wrote:
c) Create a package (linux-src?) which install the kernel sources
and provides an easy way to customize the config before making the packages
(with pkgbuild). Currently linux-grsec AUR package provides this feature by
using the MENUCONFIG
Am 27.03.2014 09:07, schrieb Nicolas Iooss:
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also
sane application policies that are missing).
I strongly disagree with removing LSM from the packaged kernel. I'm
currently using SELinux with AUR packages [1] (which I help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 27.03.2014 13:46, schrieb Thomas Bächler:
Do you even know what that means? If I see this right, every time
the kernel needs to do some permission check, it needs to ask are
we using LSM xyz?. In any case, it's more code and thus more room
Am 27.03.2014 15:24, schrieb Simon Brand:
Am 27.03.2014 13:46, schrieb Thomas Bächler:
Do you even know what that means? If I see this right, every time
the kernel needs to do some permission check, it needs to ask are
we using LSM xyz?. In any case, it's more code and thus more room
for
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris:
I want to trim our kernel down to what we actually support.
1) Once we agreed to disable one LSM, everyone else said we can enable
LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK,
Tomoyo, AppArmor and
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test
LSM. Before 3.13 kernel, users needed to recompile their kernel (or to
install linux-selinux AUR package)
On Wed, 26 Mar 2014 22:17:25 +0100
Thomas Bächler tho...@archlinux.org wrote:
Am 26.03.2014 21:31, schrieb Leonid Isaev:
On Wed, 26 Mar 2014 21:00:15 +0100
Thomas Bächler tho...@archlinux.org wrote:
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires
On Thursday, March 27, 2014 04:45:24 PM Arthur Țițeică wrote:
My opinion on this is that the kernel should be the ground on which
userspace should always work.
Features should be taken out with bug reports demonstrating
breakage in
general usage, slowdowns or security risks.
Another
TL;DR: this is a technical answer which can be seen as slightly
off-topic as it focus only on SELinux and not much about kernel config
trimming.
2014-03-27 13:46 GMT+01:00 Thomas Bächler tho...@archlinux.org:
Am 27.03.2014 09:07, schrieb Nicolas Iooss:
I agree regarding SELinux/Apparmor (it's
2014-03-27 16:31 GMT+01:00 Bigby James bigby.ja...@crepcran.com:
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test
LSM. Before 3.13 kernel, users needed to
I am a complete noob and only follow the lists out of interest. I am
also very young, so please forgive my impertinence. Thanks Thomas for
your work!! Just my 2c:
On 03/27/2014 08:34 PM, Nicolas Iooss wrote:
2014-03-27 16:31 GMT+01:00 Bigby James bigby.ja...@crepcran.com:
On Thu, Mar 27, 2014
On 27.03.2014 21:59, Bennett Piater wrote:
I am a complete noob and only follow the lists out of interest.
First lesson which also applies to a bunch of other people in this
thread: only quote what you need. 129 lines of quoted text before your
reply is bad.
signature.asc
Description:
On Thu, Mar 27, 2014 at 5:46 AM, Thomas Bächler
The fact that these LSMs must be compiled into the kernel and cannot be built
as modules tells you something important: These options change the behaviour
of the kernel at its core.
I was under the impression that this was s security feature to
On Thu, Mar 27, 2014 at 10:11 AM, Kevin Ott
This seems like it doesn't exactly fit with the Arch Way though. Arch is
supposed to be simple and minimal. Why should the default be add all
the features for a distribution that is partially based on being minimal
and lightweight?
I guess I just
On Thu, Mar 27, 2014 at 2:19 PM, Peter Baldridge petebaldri...@gmail.com
wrote:
I thought part of 'minimal' meant that the packages were as stock as
possible. I was under the impression that we shipped minimally
altered packages and it was up to the administrator to perfect each
package to
Am 27.03.2014 20:33, schrieb Nicolas Iooss:
TL;DR: this is a technical answer which can be seen as slightly
off-topic as it focus only on SELinux and not much about kernel config
trimming.
Very interesting, thanks for looking into it deeper. I'll leave most of
this uncommented.
This does
On 27 March 2014 21:34, Kevin Ott supercodingmon...@gmail.com wrote:
I'm pretty sure your summary is accurate. However, these are things done in
a configuration file when building the kernel. There isn't really a default.
There is -- download the kernel sources and run make defconfig.
It'll
On Wed, 26 Mar 2014 19:56:26 +0100
Thomas Bächler tho...@archlinux.org wrote:
Hello all,
it won't be too long until 3.14 is out and I want to address a topic
that has been bugging me for a while. Our kernel includes everything and
the kitchensink. I have no problem with delivering drivers
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires any userspace components, does it?
Currently, I boot with security=yama and completely disabled non-admin
ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama
available albeit disabled
On Wed, 26 Mar 2014 21:00:15 +0100
Thomas Bächler tho...@archlinux.org wrote:
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires any userspace components, does
it? Currently, I boot with security=yama and completely disabled
non-admin ptrace
On 26/03/14 02:56 PM, Thomas Bächler wrote:
Hello all,
it won't be too long until 3.14 is out and I want to address a topic
that has been bugging me for a while. Our kernel includes everything and
the kitchensink. I have no problem with delivering drivers that can be
built modular, but
40 matches
Mail list logo
