On 03/04/14 06:41 PM, Arthur Țițeică wrote:
> În ziua de Mie 02 Apr 2014, la 18:50:14, Daniel Micay a scris:
>> Until then, you can use any sane LSM module without recompiling the
>> kernel by building just the module you plan on using and loading it.
>
> I'm no kernel hacker by any means but AFAI
În ziua de Mie 02 Apr 2014, la 18:50:14, Daniel Micay a scris:
> Until then, you can use any sane LSM module without recompiling the
> kernel by building just the module you plan on using and loading it.
I'm no kernel hacker by any means but AFAIK the LSM framework is still there
with CONFIG_SECU
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 t
-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 c
-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 rotat
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
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 sta
Am 28.03.2014 17:11, schrieb Martti Kühne:
> On Fri, Mar 28, 2014 at 4:03 PM, Bigby James 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 sligh
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 thi
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 in
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James 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 if that "one
> day" is
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 a
On Fri, Mar 28, 2014 at 2:40 PM, Bigby James 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 measure things.
> I
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
whe
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 s
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
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 Fri, Mar 28, 2014 at 11: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 t
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 awa
On 27 March 2014 21:34, Kevin Ott 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 start with the current de
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 Thursday, March 27, 2014 02:19:28 PM Peter Baldridge 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 her liking.
>
>
On Thu, Mar 27, 2014 at 2:19 PM, Peter Baldridge
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 her liking.
The k
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
On 03/27/2014 10:06 PM, Florian Pritz wrote:
> On 27.03.2014 21:59, Bennett Piater wrote:
> 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.
Thanks for the tip, I'll remember it. :)
signat
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 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: OpenPG
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 :
>> On Thu, Mar 27, 2014 at 09:07:23AM +0100, Ni
2014-03-27 16:31 GMT+01:00 Bigby James :
> 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
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 :
> Am 27.03.2014 09:07, schrieb Nicolas Iooss:
I agree regarding SELinux/Apparmor (it's not only userspac
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.
>
> Anothe
On Wed, 26 Mar 2014 22:17:25 +0100
Thomas Bächler wrote:
> Am 26.03.2014 21:31, schrieb Leonid Isaev:
> > On Wed, 26 Mar 2014 21:00:15 +0100
> > Thomas Bächler wrote:
> >
> >> Am 26.03.2014 20:18, schrieb Leonid Isaev:
> >>> However, I don't think that Yama requires any userspace components, do
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 pack
Î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 a
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
>
-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 ro
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
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 MENUCON
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
w
Hello,
2014-03-26 20:18 GMT+01:00 Leonid Isaev :
>
> On Wed, 26 Mar 2014 19:56:26 +0100
> 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 kitchen
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
Am 26.03.2014 21:31, schrieb Leonid Isaev:
> On Wed, 26 Mar 2014 21:00:15 +0100
> Thomas Bächler 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 disabl
On Wed, 26 Mar 2014 21:00:15 +0100
Thomas Bächler 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 (kernel.yama.ptrace_scope=
On 26-03-2014 19:18, Leonid Isaev wrote:
>> 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 Yama, although we don't support the userspace for
>> any of those.
>>
>> I propose to dro
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 disab
On Wed, 26 Mar 2014 19:56:26 +0100
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
> bui
46 matches
Mail list logo
