Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Daniel Micay]

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 AFAIK the LSM framework is still there 
> with CONFIG_SECURITY, it's just the modules that are missing.

The LSM support is still there due to Yama. It would be great if support
for `ptrace_scope` was simply included in the core kernel.

Since the `protected_symlinks` and `protected_hardlinks` switches
landed, I think there's a good chance of something like this ending up
there too.

> In the end the trimming guys gain nothing because the the security "bloat" 
> (the LSM framework) is still in the kernel and the security guys lost the 
> modules. Did I get anything wrong?

Yes, you've got it wrong. The kernel logs are no longer being spammed by
useless audit crap. As I said in the email you're replying to:

> 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.

I don't think the 'security guys' lost much, considering that none of
this worked without userspace support that we do not have. SELinux and
Smack require the recompilation of userspace packages, including with
patches for SELinux. AppArmor requires kernel patches missing in the
mainline kernel to work correctly.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Arthur Țițeică]

Î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_SECURITY, it's just the modules that are missing.

In the end the trimming guys gain nothing because the the security "bloat" 
(the LSM framework) is still in the kernel and the security guys lost the 
modules. Did I get anything wrong?

-- 
Arthur Țițeică

signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Daniel Micay]

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 this stuff can be built as *modules* with no impact on
people not making use of it and someone is willing to maintain the
userspace support in the official repositories, then enabling it may
make sense.

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.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[David C. Rankin]

-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 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.
> 
> 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 important point of view should be the maintenance required to support 
> these seldom used features and I have nothing to comment on this.
> 
> Specifically regarding slowdowns, my layman opinion on this is that they are 
> meaningless in the general usage of the -ARCH kernel. 
> 
> If taking out theoretically useful features out of the kernel means that in 
> the end we gain 2 Mb of free memory or Apache is able to sustain 10500 
> connections instead of 1 I personally don't see it as good bargain.
> 
> Building a personal or an AUR linux package is easy. Maintaining one is a lot 
> harder. The most important thing that is lost in this process is the 
> community 
> support. One cannot compare the scrutiny and the testing of any AUR linux 
> package with those of the -ARCH kernel.
> 
> That being said I'd like to read and help test a before and after kernel in 
> regards to performance or any other concerning factor.
> 

First, +1 for the response.

Second, after reading this entire thread, I think it comes down to this:

  If maintaining the current config with SELinux, SMACK, etc.. support is a
significant part of maintaining the kernel package for TB, then that is the
argument for ditching it. If you are spending 30% of kernel package maintenance
time of this stuff for the benefit of a few users, then it makes sense to drop
it and let whoever uses it maintain that config, and possibly add an EXTRA/AUR
linux-SELinux-kernel-config.tar.xz package (and -SMACK, -LSM) to make that
config available so that every user who wants to build the kernel with that
support does not have to reinvent the wheel for each rebuild.

  I do not know what level of effort is involved in maintaining that config, but
if doing so requires significant effort, that effort should be borne by those
making use of it and not TB.

  If removal is needed due to claimed performance issues, then it takes
test-case evidence to support that. Otherwise, the reasoning is no better than
search location for MH370.

  I support TB's effort to trim down the config, but if providing the current
options is no-cost from a maintenance, security or performance standpoint, then
there is no reason not to provide the capability in the kernel.

  I think this discussion is well worth the effort to identify what in the
current config has a cost (in maintenance, security or performance) that
outweighs the benefit the feature provides. Those are the parts of the config
that should be trimmed and moved to user-maintenance.

- -- 
David C. Rankin, J.D.,P.E.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM8h3gACgkQZMpuZ8CyrcjpLwCeNR/NE6ya1KekdtzdgaiCRJY6
BoEAn23SlMmF6DiicHjTlK/h50ApV5WV
=aHYI
-END PGP SIGNATURE-

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[David C. Rankin]

-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 rotational disk isn't finished 
> yet because... really... I shaved twice during the HDD tests.
> 
> A side note regarding these tests: SSDs act according to their fame and HDDs 
> are as misleading as a daily horoscope.
> 
> I do plan to also test a no-debug but LSM enabled kernel even if it's just 
> for 
> the sake of statistics.
> 
> ¹ https://dl.dropboxusercontent.com/u/29107946/linux-lsm/postmark-test.ods

Arthur,

  Thank you for taking the time to do these tests. At least this provides a bit
of real-world performance data to consider. Please provide a link to the
no-debug LSM enabled kernel data when you have shaved twice-more. I'll see if I
can make a graph or two from the postmark-test.ods file. (my arts & crafts
skills are a bit rusty, so no promises)

- -- 
David C. Rankin, J.D.,P.E.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM8gc8ACgkQZMpuZ8CyrciWAgCePOf/0hN74giwdRUCpsHbUD5T
3iwAniygx5ouCZbna7VwpZMCaXbcPZKs
=3mLX
-END PGP SIGNATURE-

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Daniel Micay]

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 for
>> simplicity would ever enable it.
> 
> I think the above is a tad misleading.
> 
> While we don't yet have user space tools - which was I believe a key, if
> not critical, point Thomas was making - selinux is very useful and adds
> a strong security layer.  The kernel code is well audited and well
> tested in real world too.  Just not by us Arch folks - at least today -
> without the user space and policy support in core.

Well I don't really think it's useful, There are much simpler
alternatives, like isolating services and applications in containers
(chroot, namespaces, seccomp-bpf) and using AppArmor + the protected
symlink/hardlink switches (on by default) to pick up the slack when
you're not willing to put in much work.

Simplicity is really important in this domain, because you need to be
able to audit a full policy, and that's very difficult when data is
spread out through the filesystem. A mistake in the metadata for a
single file can break the isolation.

I don't really believe SELinux has a purpose beyond satisfying overly
complex security policies created by bureaucracy. I can't see Arch ever
being used in these situations.

> I cannot speak for AppArmor, but I do recall when the big debate to
> include it in mainline or not was going on, that Linus was a big
> proponent of using both together. Hence, today both are there.

AppArmor was not incredibly useful before Yama came along with the
protected symlink/hardlink features (now part of the core kernel). It's
useful now, but I still think you're better off using containers in most
cases. As far as I know, Linus is no fan of LSM and has done everything
he can to keep this stuff out of the core kernel. There are cases where
I think this was a mistake, like the `ptrace_scope` option requiring the
stub Yama LSM.

> And, it's not only for servers but for laptops as well. In fact newer
> versions of Android phones/tablets  use selinux enabled in enforcing
> mode. So with the right user space policies (redhat has some good base
> configs here) selinux could be a strong add for Arch linux in the future
> - maybe.

Android is not exactly a shining example of a security. SELinux hasn't
really changed anything other than adding a buzzword. The shared sdcard
data can still be read/written by any application (no permissions or
attributes there at all), and nothing else really changed. It might add
some defence in depth, but they could have gotten this by leveraging
namespaces/chroots or AppArmor too.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Arthur Țițeică]

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 standing out 
with a great difference between the stock kernel and a selinux/audit 
configured kernel. It's also a very easy test to perform.

The raw spreadsheet data and the conditions for the test may be found at ¹.
I would really appreciate some help creating some nice graphs with this data.

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 rotational disk isn't finished 
yet because... really... I shaved twice during the HDD tests.

A side note regarding these tests: SSDs act according to their fame and HDDs 
are as misleading as a daily horoscope.

I do plan to also test a no-debug but LSM enabled kernel even if it's just for 
the sake of statistics.

¹ https://dl.dropboxusercontent.com/u/29107946/linux-lsm/postmark-test.ods

-- 
Arthur Țițeică

signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Thomas Bächler]

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 slightly more convenient? What if that "one
>> day" is a year from now? Two years? And what if your time spent 
>> "experimenting"
>> leads you to conclude that these things are "factually useless" to you? What
>> then of the effort the devs put into it?
>>
> 
> 
> How did it happen that we're arguing about someone else's effort? Both
> of us are not trying to tell anyone to do anything, because people
> know that if they do something they do something and if they don't
> they don't. Stop standing in the way.

You can actually stop arguing about the SELinux issue entirely, since I
think I heard all the basic arguments on both sides (if you have
something _really_ new to add though, feel free to do so). I'll make up
my mind about it and decide how we proceed.




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Genes Lists]

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 think the above is a tad misleading.

While we don't yet have user space tools - which was I believe a key, if 
not critical, point Thomas was making - selinux is very useful and adds 
a strong security layer.  The kernel code is well audited and well 
tested in real world too.  Just not by us Arch folks - at least today - 
without the user space and policy support in core.


I cannot speak for AppArmor, but I do recall when the big debate to 
include it in mainline or not was going on, that Linus was a big 
proponent of using both together. Hence, today both are there.


And, it's not only for servers but for laptops as well. In fact newer 
versions of Android phones/tablets  use selinux enabled in enforcing 
mode. So with the right user space policies (redhat has some good base 
configs here) selinux could be a strong add for Arch linux in the future 
- maybe.


The discussion here, I thought, was whether having it in the stock Arch 
kernel offers any value to the community today. As Thomas said - it's 
pretty easy to build a custom kernel via abs if you want to work on user 
space policy etc.


I would actually like to see Arch have selinux support - it would make 
us stronger - but we just don't have the tools and policies today.


gene

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Bigby James]

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 installing
third-party userspace packages then they are, in fact, useless to you. If you
don't contribute code to the kernel, the kernel debugging features (which eat up
a lot of build time) are almost certainly, in fact, useless to you. Such is the
case for everything found in the kernel: Someone, somewhere will find it useful,
and that's a fact. Whether the majority of Arch users find it useful, and it
therefore should be maintained by a limited staff with limited resources, is
what's in question here.
-- 
"A common mistake that people make when trying to design something completely 
foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[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 slightly more convenient? What if that "one
> day" is a year from now? Two years? And what if your time spent 
> "experimenting"
> leads you to conclude that these things are "factually useless" to you? What
> then of the effort the devs put into it?
>


How did it happen that we're arguing about someone else's effort? Both
of us are not trying to tell anyone to do anything, because people
know that if they do something they do something and if they don't
they don't. Stop standing in the way.

cheers!
mar77i

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Bigby James]

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 in the AUR, and about the fact that they weren't even being properly
maintained. It doesn't refer to the in-kernel modules/code.

> 
> If a justifiable amount of effort saves a significant amount of time
> and energy for the few people who use it, I'm in favor of the security
> features being there so I have them at my disposal in case I would
> decide to experiment with them one day too. 

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 a year from now? Two years? And what if your time spent "experimenting"
leads you to conclude that these things are "factually useless" to you? What
then of the effort the devs put into it? 

As I mentioned above regarding the thread you linked to, the person previously
maintaining the userspace packages couldn't keep them up-to-date. The Arch devs
don't maintain Arch for a living; their lives are no less complicated than the
rest of ours. I'll gladly admit that the reason I'm all for eliminating these
things is because I have no use for them myself, and removing them when I build
my own kernel makes configuration slightly more inconvenient than it would be if
they weren't there in the first place, and since no one seems to really use them
regularly, there's no real sense in keeping them. But ultimately, if more people
did use these things than didn't, and the devs deemed it worth their time to
maintain them, then my own concerns are moot. They keep the OS I love stable and
versatile; if deciding either keeping something I don't care for or eliminating
something I find useful makes it easier for them to handle Arch development and
maintainance, that counts for more than my convenience.
-- 
"A common mistake that people make when trying to design something completely 
foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Martti Kühne]

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. 
> If

I fully agree. Neither is common sense, obviously.

> you don't personally configure the features in question by installing
> third-party userspace packages then they are, in fact, useless to you. If you

Well, they came in when people argued in favor of them. [0]

> don't contribute code to the kernel, the kernel debugging features (which eat 
> up
> a lot of build time) are almost certainly, in fact, useless to you. Such is 
> the

I guess we all agree about the debugging features.

> case for everything found in the kernel: Someone, somewhere will find it 
> useful,
> and that's a fact. Whether the majority of Arch users find it useful, and it
> therefore should be maintained by a limited staff with limited resources, is
> what's in question here.

If a justifiable amount of effort saves a significant amount of time
and energy for the few people who use it, I'm in favor of the security
features being there so I have them at my disposal in case I would
decide to experiment with them one day too. The hurdle to consider
such features is higher if they aren't in the official kernel, as
building a kernel takes time and caution. What will actually happen is
fully that person's decision who will or will not implement change.
And no, I'm not aware of any decisions around Arch needed any kind of
majority.

Good day.
mar77i

[0] 
https://mailman.archlinux.org/pipermail/arch-general/2013-November/034385.html

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Mario Rugiero]

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
whenever possible. Lastly, any decision taken will hurt someone. You keep
the features? Then the ones who want the lighter, simpler kernel will
suffer from a less tested build. You drop them? Servers (and any other
user, whatever reason) will suffer from the same. However, the code paths
they use exclusively are really not tested more by being in the main repos.
Why? Because the ones using it, use it through AUR packages. If the feature
is unusable without AUR packages, then they effectively get testing only
from the ones who install AUR packages. Sure, they have some extra
guarantee that drivers are not broken (except if they behave differently
under AppArmor, SELinux, etc, do they?), but they don't have any testing on
the actual features that are being included only because they use them.
Needless to say, I'm all in favor of using minimal builds by default.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Bigby James]

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 there are no bug reports or any other solid evidence that the 
> kernel 
> ate their computers since apparmor, selinux and audit were semi-silently 
> enabled a few builds back.
> 
> The facts will remain though:
> 
> * the kernel will still be "everything and the kitchen sink".
> * no provable performance enhancement so far.
> * security measures will get back at square 1.
> 

There seems to be a general, significant misunderstanding floating around this
thread. The "security features" in question are not passive; their mere
existence within the binary kernel does not improve security. They are modules
that allow users to fine-tune certain security features through the kernel using
third-party tools, features that are almost exclusively useful for server
administration (since, if you're the only one with access to your single-user
machine, they won't tell you anything you can't already see without them).

If you've never installed and configured the SELinux/AppArmor/Tomoyo userspace
packages, you've never had the security they purport to provide. Hence the point
of removing their modules from the kernel isn't performance; it's that  *no one
uses them,* and they clutter up the kernel configuration for no good reason at
all, making it more tedious to maintain and just a bit more annoying to
configure for individual users for absolutely no benefit.

-- 
"A common mistake that people make when trying to design something completely 
foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Daniel Micay]

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 be disabled by default (as far as
>> I am aware) so that it can be enabled with 'audit=1' on the command line.
> 
> I couldn't find a definitive answer but the two documents I did find ¹² 
> suggest that having selinux and audit fully functional (not just enabled) has 
> no real performance impact.
> 
> Kernel debugging options on the other side seem to have a much bigger impact.
> 
> It raises a question mark that the two most important components of a system 
> (systemd and the kernel) have security measures disabled.

These 'security measures' do nothing but provide hooks for malware to
latch onto. Audit and LSM are a rootkit author's wet dream. It's
strictly a security *improvement* to have them disabled if there's no
userspace support as it just increases the kernel surface area and
provides more useful post-exploitation tools.

Claiming that we will have 'security measures disabled' is just
hyperbole when Arch Linux is shipping with protected symlinks,
hardlinks, ptrace_scope=1 and stack smashing protection. It certainly
doesn't disable namespaces and seccomp-bpf.

> People in this thread like to put out the over subjective "lightweight" 
> factor 
> but still there are no bug reports or any other solid evidence that the 
> kernel 
> ate their computers since apparmor, selinux and audit were semi-silently 
> enabled a few builds back.

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.

It's the same kind of hogwash as Windows security tokens, where it looks
great from a theoretical point of view but is far too complex to
actually use correctly. The Chromium sandbox is broken over and over on
Windows because this complex token design simply doesn't work. On Linux,
it uses a simple chroot, namespaces and seccomp whitelist. It doesn't
ever get in the way of users, and it's easy for any developer to understand.

If a story ran on the Guardian tomorrow showing that the NSA
open-sourced SELinux to set back the development of MAC by *years* by
sending people down the wrong path, I would not be the least bit
surprised. :P

> The facts will remain though:
> 
> * the kernel will still be "everything and the kitchen sink".
> * no provable performance enhancement so far.
> * security measures will get back at square 1.

Neither AppArmor or SELinux is provided in the official repositories, so
enabling these in the kernel only adds attack surface. I doubt that
using AUR packages provided by a different group of maintainers every
week is going to improve anyone's security. If someone wants to attack
Arch users, their easiest shot at it is taking over a somewhat popular
AUR package (like apparmor) and sticking some subtly malicious code in
the source or install file.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Mauro Santos]

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 reports or any other solid evidence that the 
> kernel 
> ate their computers since apparmor, selinux and audit were semi-silently 
> enabled a few builds back.

Of the people that have pkgstats installed, almost no one is using any
of the security features, selinux and apparmor don't even register in
the stats [1], if they are not being used I don't see how
removing/disabling them makes for a less secure system.

Using selinux/apparmor/tomoyo requires comprehensive well written rules,
which no one is willing to maintain because it is a huge and hard job.
Things will subtly break after a while if rules are not rechecked with
every package update, it's not a matter of if but when will they break,
specially with arch that keeps close to the latest upstream releases.

People have complained that audit pollutes their logs and apparently it
is broken for containers and has to be disabled it with audit=0.

Less code means less bugs and a smaller attack surface, and I suppose
less of a burden for the one(s) actually maintaining the kernel package.

If no one comes forward and says: please don't remove features a b and c
because I'm actually making use of them in a production system, then I
suppose the features will be removed.

[1] https://www.archlinux.de/?page=PackageStatistics

-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Martti Kühne]

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 to configure audit to be disabled by default (as far as
>> I am aware) so that it can be enabled with 'audit=1' on the command line.
>
> I couldn't find a definitive answer but the two documents I did find ¹²
> suggest that having selinux and audit fully functional (not just enabled) has
> no real performance impact.
>
> Kernel debugging options on the other side seem to have a much bigger impact.
>
> 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 reports or any other solid evidence that the kernel
> ate their computers since apparmor, selinux and audit were semi-silently
> enabled a few builds back.
>

Exactly my thoughts about this thread.
http://i.imgur.com/nfFuu.jpg

I'm very much for cleaning up the kernel config from things that
factually are useless.
Thanks for reading up everyone and keep trying to not step on each other's toes.

cheers!
mar77i

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Arthur Țițeică]

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) so that it can be enabled with 'audit=1' on the command line.

I couldn't find a definitive answer but the two documents I did find ¹² 
suggest that having selinux and audit fully functional (not just enabled) has 
no real performance impact.

Kernel debugging options on the other side seem to have a much bigger impact.

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 reports or any other solid evidence that the kernel 
ate their computers since apparmor, selinux and audit were semi-silently 
enabled a few builds back.

The facts will remain though:

* the kernel will still be "everything and the kitchen sink".
* no provable performance enhancement so far.
* security measures will get back at square 1.

¹ http://www.phoronix.com/scan.php?page=article&item=fedora_debug_selinux
² 
https://dl.dropboxusercontent.com/u/29107946/Assessing-the-Performance-Impact-of-the-Linux-Kernel-Audit-Trail.pdf

As a side note I will try to test the worst case scenario in the Phoronix 
tests -- Postmark, and post the results here.

-- 
Arthur Țițeică

signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[WorMzy Tykashi]

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 default for the architecture you're
building on [1 - x86_64][1 - i386], (which might not be up-to-date),
then sets any new flags to their default state.

I dunno how usable the default config is though, presumably not very,
or else Arch wouldn't deviate so from the defaults so much as to need
to ship custom configs with ABS.


WorMzy

[1 - x86_64] 
https://github.com/torvalds/linux/blob/master/arch/x86/configs/x86_64_defconfig
[1 - i386] 
https://github.com/torvalds/linux/blob/master/arch/x86/configs/i386_defconfig

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Thomas Bächler]

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 sound weird. Could you please give me some references to
> this so that I can understand better? I only know that SELinux uses
> the audit subsystem to report denials and that the audit subsystem can
> be disabled at boot time using "audit=0" kernel command line parameter
> (and also I've read
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/audit.c?id=v3.13#n1001).

Okay, you are right, it wasn't AppArmor, it was SELinux. According to
Kconfig, SELinux depends on Audit.

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) so that it can be enabled with 'audit=1' on the command line.

As long as SELinux needs audit and audit is enabled by default, SELinux
will not make it to the 3.14+ versions of our linux package.




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Kevin Ott]

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.
> 
> I thought we only make a few little patches to the default kernel in
> the repo and anyone who wants to strip drivers and use BFS is welcome
> to do so through the AUR and/or ABS.
> 
> I don't really use stock kernel so it doesn't matter to me, but for
> point of reference, (and please correct me if I'm wrong here) I
> thought default in the repos was the generally accepted Arch Way.

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".

So the question then becomes: Should the default build for the kernel 
contain "everything and the kitchensink [sic]"?

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Joel Teichroeb]

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 kernel doesn't need to be patched to remove any of this functionality.
It's all done though the kernel configuration file which isn't supplied
upstream.



Joel

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Peter Baldridge]

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 don't see the reason for adding in feature by default that
> so few people will actually use. And the people who will be using it
> should have the knowledge and ability  to build their own kernel that will
> have those features enabled.

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.

I thought we only make a few little patches to the default kernel in
the repo and anyone who wants to strip drivers and use BFS is welcome
to do so through the AUR and/or ABS.

I don't really use stock kernel so it doesn't matter to me, but for
point of reference, (and please correct me if I'm wrong here) I
thought default in the repos was the generally accepted Arch Way.

-- 
Pete

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Bennett Piater]

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. :)



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Peter Baldridge]

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 make it
a bit more difficult to switch off your configured LSM.

-- 
Pete

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Florian Pritz]

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: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Bennett Piater]

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, 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) to be able to use SELinux. This is
>>> a hard first step and I know too many people who thinks "I don't want
>>> to recompile my kernel as I've already done magical things to make my
>>> graphic card works and I don't want to break my fragile config". Now
>>> people just needs to install packages (from unofficial repos or from
>>> the AUR) as described in the wiki [4] and reboot to start using
>>> SELinux.
>>> * Second, it's possible to compile things which are disabled at
>>> runtime. For example, I don't need to compile the kernel without IPv4
>>> to test what breaks when running a non-IPv4 kernel, I only need to add
>>> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
>>> for LSM. Even if they are compiled, they can be enabled/disabled with
>>> such runtime configuration and this config doesn't require much work.
>>> * Third, users who want to combine several unofficial features for
>>> their kernel already have to do weird things. For example, I'm using a
>>> grsec kernel with SELinux. A few months ago, there were linux-grsec
>>> and linux-selinux in the AUR but no package which provided both. Hence
>>> I needed to build a custom package to have both. Now, the next time
>>> linux-grsec's maintainer will sync its config with the official repo,
>>> SELinux will be available in this package (unless I've missed
>>> something) and I'll no longer need to build my custom kernel.
>>
>> As a lowly end-user, I'll have to disagree with you. The bulk of your 
>> reasoning
>> comes down to "*I* use it, so don't take it away from me." But your case is
>> hardly representative; I highly doubt that the typical desktop user (that is,
>> the typical Arch user) makes use of SELinux or its cohorts; no doubt there 
>> are
>> people running Arch servers that use it, but again that's not representative 
>> of
>> the community at large, in which many people just install Arch on their 
>> laptops
>> and desktops for everyday production and entertainment use.
>>  
>> When I build a custom kernel for my laptop, the LSM stuff and kernel 
>> debugging
>> options are the first to go, as they have absolutely no benefit for someone 
>> who
>> uses a computer primarily for reasearch and writing, coding and design work, 
>> web
>> browsing and music.  They're complements for specific use-cases---server
>> administration (most likely when multiple users are involved) and kernel
>> hacking, respectively---and are of no use to anyone who doesn't partake in 
>> those
>> use-cases (how necessary is MAC to someone who interacts with and monitors a
>> single machine all day?). Besides, as you've said, you already need to build 
>> the
>> userspace utilities from source (because not too long ago, the devs voiced 
>> their
>> opposition to maintaining SELinux officially), so leaving such features in 
>> the
>> kernel to ease "testing" is both specious and a mismeasure of how useful or
>> vital they might be. Suppose the majority of people who test SELinux decide 
>> to
>> drop it, as seems to be the case in my (admittedly limited) observations. Of
>> what value, then, is the work the devs did to maintain it?
>>
> Sorry if my message sounded too much as "I use it so I want other people
> to make my life easier". That was not the intended tone at all. If you
> need a bit more background about how I use ArchLinux, let me say I'm
> using it on my laptop, where I don't fear to do things that breaks my
> system (and if often breaks) because I have easy physical access. When I
> needed to set up SELinux on a server (not running Arch) a few months
> ago, I decided to first familiarize myself with this software on my
> laptop. It took me a long time before having a working system and I'm
> trying to reduce that time for other users who might have same ideas as
> I (eg. by reporting and helping fixing bugs like
> http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg9.html).
> 
> Of course, I'm biased when I speak of SELinux so basically I try to
> imagine the state of mind of "normal" people by replacing "SELinux" with
> "Linux containers", which I've never used and see as unneeded weight
> (this is a biased unmotivated statement which may be untrue). I don't
> know if currently to run LXC or systemd-nspawn you need to recompile
> your kernel, but you need at least UTS namespaces, network namespaces...
> and I don't know if anyone will consider disabling these featu

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

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 kernel (or to
>> install linux-selinux AUR package) to be able to use SELinux. This is
>> a hard first step and I know too many people who thinks "I don't want
>> to recompile my kernel as I've already done magical things to make my
>> graphic card works and I don't want to break my fragile config". Now
>> people just needs to install packages (from unofficial repos or from
>> the AUR) as described in the wiki [4] and reboot to start using
>> SELinux.
>> * Second, it's possible to compile things which are disabled at
>> runtime. For example, I don't need to compile the kernel without IPv4
>> to test what breaks when running a non-IPv4 kernel, I only need to add
>> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
>> for LSM. Even if they are compiled, they can be enabled/disabled with
>> such runtime configuration and this config doesn't require much work.
>> * Third, users who want to combine several unofficial features for
>> their kernel already have to do weird things. For example, I'm using a
>> grsec kernel with SELinux. A few months ago, there were linux-grsec
>> and linux-selinux in the AUR but no package which provided both. Hence
>> I needed to build a custom package to have both. Now, the next time
>> linux-grsec's maintainer will sync its config with the official repo,
>> SELinux will be available in this package (unless I've missed
>> something) and I'll no longer need to build my custom kernel.
> 
> As a lowly end-user, I'll have to disagree with you. The bulk of your 
> reasoning
> comes down to "*I* use it, so don't take it away from me." But your case is
> hardly representative; I highly doubt that the typical desktop user (that is,
> the typical Arch user) makes use of SELinux or its cohorts; no doubt there are
> people running Arch servers that use it, but again that's not representative 
> of
> the community at large, in which many people just install Arch on their 
> laptops
> and desktops for everyday production and entertainment use.
>  
> When I build a custom kernel for my laptop, the LSM stuff and kernel debugging
> options are the first to go, as they have absolutely no benefit for someone 
> who
> uses a computer primarily for reasearch and writing, coding and design work, 
> web
> browsing and music.  They're complements for specific use-cases---server
> administration (most likely when multiple users are involved) and kernel
> hacking, respectively---and are of no use to anyone who doesn't partake in 
> those
> use-cases (how necessary is MAC to someone who interacts with and monitors a
> single machine all day?). Besides, as you've said, you already need to build 
> the
> userspace utilities from source (because not too long ago, the devs voiced 
> their
> opposition to maintaining SELinux officially), so leaving such features in the
> kernel to ease "testing" is both specious and a mismeasure of how useful or
> vital they might be. Suppose the majority of people who test SELinux decide to
> drop it, as seems to be the case in my (admittedly limited) observations. Of
> what value, then, is the work the devs did to maintain it?
> 
Sorry if my message sounded too much as "I use it so I want other people
to make my life easier". That was not the intended tone at all. If you
need a bit more background about how I use ArchLinux, let me say I'm
using it on my laptop, where I don't fear to do things that breaks my
system (and if often breaks) because I have easy physical access. When I
needed to set up SELinux on a server (not running Arch) a few months
ago, I decided to first familiarize myself with this software on my
laptop. It took me a long time before having a working system and I'm
trying to reduce that time for other users who might have same ideas as
I (eg. by reporting and helping fixing bugs like
http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg9.html).

Of course, I'm biased when I speak of SELinux so basically I try to
imagine the state of mind of "normal" people by replacing "SELinux" with
"Linux containers", which I've never used and see as unneeded weight
(this is a biased unmotivated statement which may be untrue). I don't
know if currently to run LXC or systemd-nspawn you need to recompile
your kernel, but you need at least UTS namespaces, network namespaces...
and I don't know if anyone will consider disabling these features, but I
expect voices to be raised if someone thinks of removing CONFIG_UTS_NS
and CONFIG_NET_NS (or are such decisions expected to happen without
anybody noticing?).

>> That been said, I agree that having a kernel with less features would
>> be good. To my mind, here are possible ways :
>>
>> a) Create a linux-light

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[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.

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 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
>> to maintain) and a custom policy (basically a mix of Tresys'
>> Reference Policy, Fedora policy and Debian patches [2]) and it
>> works fine. The only reason behind "why nobody hasn't asked yet
>> to make libselinux and libsepol official packages?" is that
>> before this happens, the current maintainer of these AUR packages
>> wants a working SELinux policy [3].
>
> You use AUR packages for all kinds of SELinux stuff, so why not use
> a custom kernel for that?

Because there is a chicken-and-egg issue here. The long term
motivation is to migrate SELinux-compiled duplicated packages (like
sudo, systemd...) from the AUR to official packages ("long term"
meaning "no timeline can be given as there are way too many people
against it"). Currently there is a security issue due to package
duplication in the AUR (when a security patch is made for systemd for
example, it takes some time before systemd-selinux is updated). I
won't discuss this more in this thread as it is off topic.
>
>> 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) to be able to
>> use SELinux.
>
> So, installing packages from AUR is easy, _except_ when you need
> to install the kernel?

Yes, because there is no easy way to "mix two packages". I don't know
any other software which is provided in different packages depending
on their configuration. Most Archlinux packages support via
configure-time switches many things I've never heard about. Why would it
be different for the kernel? (I'm expecting people to ask me this
question and as I don't have any relevant answer yet, I ask it here.)
>
>> This is a hard first step and I know too many people who thinks
>> "I don't want to recompile my kernel as I've already done magical
>> things to make my graphic card works and I don't want to break my
>> fragile config". Now people just needs to install packages (from
>> unofficial repos or from the AUR) as described in the wiki [4]
>> and reboot to start using SELinux.
>
> So, install a kernel from unofficial repositories or AUR? It's
> "just a package".

If you installed modules with DKMS, you also need to recompile these
modules and it may break. I agree that "it's just a package" and
"nothing should break", but that's just theory and in the real world,
things like unsupported DKMS modules break with a custom kernel and
this increases the difficulty a lot. However this increases the
maintenance burden of unsupported things so it's not relevant here.
>
>> * Second, it's possible to compile things which are disabled at
>> runtime.
>
> That they are disabled at runtime does not mean that they have no
> impact at runtime. At best, it's "only" a performance impact and at
> worst, it even causes problems. The whole idea is to make the
> kernel smaller and to avoid problems caused by things we don't make
> use of.
>
>> Even if they are compiled, they can be enabled/disabled with such
>> runtime configuration and this config doesn't require much work.
>
> 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 failure.

According to
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/security.c?id=v3.13
and
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c?id=v3.13#n5977
, the security checks are done using a structure of function pointers
(struct security_operations *security_ops) and the execution path to
check a file permission (at
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/read_write.c#n367
for example) looks exactly the same in both "SELinux not compiled" and
"SELinux compiled but disabled" configurations. I may have misunderstood
the code, in such case I'd be glad if you correct me.
>
> I see where you are coming from and I used to think the same way.
> But after we enabled AppArmor and SELinux in 3.13, the audit
> subsystem was silently enabled - and it is _on_ by default. This
> whole story got me thinking, do we even have any idea what the
> consequences of adding these features are? And I don't think we
> do.

This does sound weird. Could you please give me some references to
this so that I can understand better? I only

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Kevin Ott]

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 important point of view should be the maintenance required to
> support these seldom used features and I have nothing to comment 
on this.
> 
> Specifically regarding slowdowns, my layman opinion on this is that 
they are
> meaningless in the general usage of the -ARCH kernel.
> 
> If taking out theoretically useful features out of the kernel means that 
in
> the end we gain 2 Mb of free memory or Apache is able to sustain 
10500
> connections instead of 1 I personally don't see it as good 
bargain.

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 don't see the reason for adding in feature by default that 
so few people will actually use. And the people who will be using it 
should have the knowledge and ability  to build their own kernel that will 
have those features enabled.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Leonid Isaev]

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, 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 by default (as they now do).
> >>
> >> Once yama is built-in, the ptrace_scope protection is enabled by
> >> default. There is no option to change that.
> >>
> > 
> > But by default, kernel.yama.ptrace_scope = 0
> 
> No. The default is 1.
> 

Yes, you are right, I was speaking from the old memory... If this causes
problems and a default sysctl.d/ conf file is not desired, then I guess, Yama
can go away as well.

Does this discussion also apply to the -lts kernel?

Thanks,
-- 
Leonid Isaev
GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


signature.asc
Description: PGP signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[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 kernel (or to
> install linux-selinux AUR package) to be able to use SELinux. This is
> a hard first step and I know too many people who thinks "I don't want
> to recompile my kernel as I've already done magical things to make my
> graphic card works and I don't want to break my fragile config". Now
> people just needs to install packages (from unofficial repos or from
> the AUR) as described in the wiki [4] and reboot to start using
> SELinux.
> * Second, it's possible to compile things which are disabled at
> runtime. For example, I don't need to compile the kernel without IPv4
> to test what breaks when running a non-IPv4 kernel, I only need to add
> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
> for LSM. Even if they are compiled, they can be enabled/disabled with
> such runtime configuration and this config doesn't require much work.
> * Third, users who want to combine several unofficial features for
> their kernel already have to do weird things. For example, I'm using a
> grsec kernel with SELinux. A few months ago, there were linux-grsec
> and linux-selinux in the AUR but no package which provided both. Hence
> I needed to build a custom package to have both. Now, the next time
> linux-grsec's maintainer will sync its config with the official repo,
> SELinux will be available in this package (unless I've missed
> something) and I'll no longer need to build my custom kernel.

As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning
comes down to "*I* use it, so don't take it away from me." But your case is
hardly representative; I highly doubt that the typical desktop user (that is,
the typical Arch user) makes use of SELinux or its cohorts; no doubt there are
people running Arch servers that use it, but again that's not representative of
the community at large, in which many people just install Arch on their laptops
and desktops for everyday production and entertainment use.
 
When I build a custom kernel for my laptop, the LSM stuff and kernel debugging
options are the first to go, as they have absolutely no benefit for someone who
uses a computer primarily for reasearch and writing, coding and design work, web
browsing and music.  They're complements for specific use-cases---server
administration (most likely when multiple users are involved) and kernel
hacking, respectively---and are of no use to anyone who doesn't partake in those
use-cases (how necessary is MAC to someone who interacts with and monitors a
single machine all day?). Besides, as you've said, you already need to build the
userspace utilities from source (because not too long ago, the devs voiced their
opposition to maintaining SELinux officially), so leaving such features in the
kernel to ease "testing" is both specious and a mismeasure of how useful or
vital they might be. Suppose the majority of people who test SELinux decide to
drop it, as seems to be the case in my (admittedly limited) observations. Of
what value, then, is the work the devs did to maintain it?

> That been said, I agree that having a kernel with less features would
> be good. To my mind, here are possible ways :
> 
> a) Create a linux-light package with less features than the linux
> package, and don't trim linux' configuration.
> b) Rename linux as "linux-full" (as an official package) and trim linux' 
> config.
> 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 environment variable [5].
> d) Don't create new packages and trim linux' config (this is your
> idea, if I understood correctly).
> 
> Any of a) or b) would suits fine for me if you choose to drop LSM in
> the lighter config.
> 

I've used Arch for years now, but I can remember what it was like as a n00b.
>From the perspective of someone who is new to Arch, this is grossly misleading.
Someone unfamiliar with how Arch packaging works (or a long-term Archer who
doesn't pay close enough attention to the news and mailing lists) will
conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and
"linux-src" = "I have to screw with it for two hours to get my GPU working."
They'll likely just install linux-full anyway, unaware of the distinction. 

It seems far more reasonable to me to trim the kernel to those things typical of
everyday desktop use, and trust that members of the community will maintain
those things which they find useful separately. I don't mean to be presumptuous,
but it's my understanding that the primary goal of the Arch devs and repo
maintainers is to provide a minimal, functiona

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Arthur Țițeică]

Î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 Yama, although we don't support the userspace for
> any of those.

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 important point of view should be the maintenance required to support 
these seldom used features and I have nothing to comment on this.

Specifically regarding slowdowns, my layman opinion on this is that they are 
meaningless in the general usage of the -ARCH kernel. 

If taking out theoretically useful features out of the kernel means that in 
the end we gain 2 Mb of free memory or Apache is able to sustain 10500 
connections instead of 1 I personally don't see it as good bargain.

Building a personal or an AUR linux package is easy. Maintaining one is a lot 
harder. The most important thing that is lost in this process is the community 
support. One cannot compare the scrutiny and the testing of any AUR linux 
package with those of the -ARCH kernel.

That being said I'd like to read and help test a before and after kernel in 
regards to performance or any other concerning factor.

-- 
Arthur Țițeică

signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Thomas Bächler]

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 failure.
> 
> Not necessarily, i do not know the code of all the policy enforcement
> points, but if you have a function pointer to the policy decision
> function, you only have to query this function. So if you enable
> SELinux, you let the pointer point to the SELinux function.

Do you know that Linux operates this way? If so, at least we don't have
to assume that performance suffers. This again begs the question, why do
the LSMs need to be built-in? Why can't they be modular?

I don't expect you to answer these questions, they are just things that
I consider.

Perhaps let me rephrase my rationale: If we include support for an LSM
in Linux, it should be because we support it in our user-space, too. I
don't see SELinux being supported by default in Arch anytime soon. _If_
at some point we make a decision to support it (optional or by default),
we can enable it in the kernel.

The whole idea of trimming down the kernel is to stop enabling things
because some users _may_ _possibly_ want to use them.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Simon Brand]

-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 
> for failure.

Not necessarily, i do not know the code of all the policy enforcement
points, but if you have a function pointer to the policy decision
function, you only have to query this function. So if you enable
SELinux, you let the pointer point to the SELinux function.


Maybe you don't understand what i mean because of my bad english, here
an example code:

int (*func)( char *arg, ... );
int SELinux_pdp( char *arg, ... ) { Code }
int pdp( char *arg, ... ) { Code }

if( SELinux ) {
func = &SELinux_pdp;
} else {
func = &pdp;
}


So you only have to call func( arg, ... ) and test the returned value.


Besides that, i'd prefer a smaller kernel, too.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlM0NKkACgkQkr64biT2RYQzegD+MU+yBgTPoIA0RB9CH9l2CFpp
dEEGg5FfYVdodSYtAGsA/jOmUhnz+DvogZDYVHpsPmjObexou6qcGRpJPMxIL8jK
=igbX
-END PGP SIGNATURE-

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Thomas Bächler]

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 to
> maintain) and a custom policy (basically a mix of Tresys' Reference
> Policy, Fedora policy and Debian patches [2]) and it works fine. The
> only reason behind "why nobody hasn't asked yet to make libselinux and
> libsepol official packages?" is that before this happens, the current
> maintainer of these AUR packages wants a working SELinux policy [3].

You use AUR packages for all kinds of SELinux stuff, so why not use a
custom kernel for that?

> 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) to be able to use SELinux.

So, installing packages from AUR is easy, _except_ when you need to
install the kernel?

> This is
> a hard first step and I know too many people who thinks "I don't want
> to recompile my kernel as I've already done magical things to make my
> graphic card works and I don't want to break my fragile config". Now
> people just needs to install packages (from unofficial repos or from
> the AUR) as described in the wiki [4] and reboot to start using
> SELinux.

So, install a kernel from unofficial repositories or AUR? It's "just a
package".

> * Second, it's possible to compile things which are disabled at
> runtime.

That they are disabled at runtime does not mean that they have no impact
at runtime. At best, it's "only" a performance impact and at worst, it
even causes problems. The whole idea is to make the kernel smaller and
to avoid problems caused by things we don't make use of.

> Even if they are compiled, they can be enabled/disabled with
> such runtime configuration and this config doesn't require much work.

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 failure.

I see where you are coming from and I used to think the same way. But
after we enabled AppArmor and SELinux in 3.13, the audit subsystem was
silently enabled - and it is _on_ by default. This whole story got me
thinking, do we even have any idea what the consequences of adding these
features are? And I don't think we do.

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 don't have a really strong argument against these options, except that
once we enable them, we need to deal with problems that they may cause
users. I think we are better off going with what the majority of Arch
users use these days (simple DAC LSM) and let everyone else deal with
their use case themselves.

> * Third, users who want to combine several unofficial features for
> their kernel already have to do weird things.

Users competent enough to do weird things can compile their own kernels.

> a) Create a linux-light package with less features than the linux
> package, and don't trim linux' configuration.
> b) Rename linux as "linux-full" (as an official package) and trim linux' 
> config.

I won't maintain two kernels just for the sake of feature-creep.

> 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 environment variable [5].

What is this supposed to do? Makepkg is for building packages, pacman is
for installing binaries. If you want automated package building on
upgrades, use Gentoo.

> d) Don't create new packages and trim linux' config (this is your
> idea, if I understood correctly).




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Paul Gideon Dann]

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 environment variable [5].

One of my machines requires a patched kernel, but I've never felt the need for 
a linux-src 
package. I use Yaourt as an ABS client, but there are others available:

# yaourt -G linux
# cd linux
--- do patching ---
# makepkg

The PKGBUILD even contains instructions on how to tweak the configuration, if I 
remember correctly.

Paul

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Savyasachee Jha]

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
working on a working Arch SELinux Policy, I think that having something
like the SELinux LSM is not really a burden on the user.

On the other hand, (seeing that it has come up) a package like
linux-sources would be wonderful. In short, I think that for something as
essential as the kernel, having multiple configurations (viz. linux,
linux-lts, linux-light and linux-sources) in the official repos is a pretty
good idea. I hope it can be realised.


On Thu, Mar 27, 2014 at 5:07 PM, Nicolas Iooss wrote:

> 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 kitchensink. I have no problem with delivering drivers that can be
> > > built modular, but there are other things that have an unknown impact
> on
> > > everyone.
> > >
> > > I want to trim our kernel down to what we actually support.
> >
> > Thanks for doing this.
> >
> > >
> > > 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 drop all of them.
> >
> > 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 to
> maintain) and a custom policy (basically a mix of Tresys' Reference
> Policy, Fedora policy and Debian patches [2]) and it works fine. The
> only reason behind "why nobody hasn't asked yet to make libselinux and
> libsepol official packages?" is that before this happens, the current
> maintainer of these AUR packages wants a working SELinux policy [3].
>
> 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) to be able to use SELinux. This is
> a hard first step and I know too many people who thinks "I don't want
> to recompile my kernel as I've already done magical things to make my
> graphic card works and I don't want to break my fragile config". Now
> people just needs to install packages (from unofficial repos or from
> the AUR) as described in the wiki [4] and reboot to start using
> SELinux.
> * Second, it's possible to compile things which are disabled at
> runtime. For example, I don't need to compile the kernel without IPv4
> to test what breaks when running a non-IPv4 kernel, I only need to add
> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
> for LSM. Even if they are compiled, they can be enabled/disabled with
> such runtime configuration and this config doesn't require much work.
> * Third, users who want to combine several unofficial features for
> their kernel already have to do weird things. For example, I'm using a
> grsec kernel with SELinux. A few months ago, there were linux-grsec
> and linux-selinux in the AUR but no package which provided both. Hence
> I needed to build a custom package to have both. Now, the next time
> linux-grsec's maintainer will sync its config with the official repo,
> SELinux will be available in this package (unless I've missed
> something) and I'll no longer need to build my custom kernel.
>
> That been said, I agree that having a kernel with less features would
> be good. To my mind, here are possible ways :
>
> a) Create a linux-light package with less features than the linux
> package, and don't trim linux' configuration.
> b) Rename linux as "linux-full" (as an official package) and trim linux'
> config.
> 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 environment variable [5].
> d) Don't create new packages and trim linux' config (this is your
> idea, if I understood correctly).
>
> Any of a) or b) would suits fine for me if you choose to drop LSM in
> the lighter config.
>
> Regards,
>
> Nicolas
>
> [1] https://github.com/Siosm/siosm-selinux
> [2] https://github.com/fishilico/selinux-refpolicy-patched
> [3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261
> [4] https://wiki.archlinux.org/index.php/SELinux
> [

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

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 kitchensink. I have no problem with delivering drivers that can be
> > built modular, but there are other things that have an unknown impact on
> > everyone.
> >
> > I want to trim our kernel down to what we actually support.
>
> Thanks for doing this.
>
> >
> > 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 drop all of them.
>
> 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 to
maintain) and a custom policy (basically a mix of Tresys' Reference
Policy, Fedora policy and Debian patches [2]) and it works fine. The
only reason behind "why nobody hasn't asked yet to make libselinux and
libsepol official packages?" is that before this happens, the current
maintainer of these AUR packages wants a working SELinux policy [3].

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) to be able to use SELinux. This is
a hard first step and I know too many people who thinks "I don't want
to recompile my kernel as I've already done magical things to make my
graphic card works and I don't want to break my fragile config". Now
people just needs to install packages (from unofficial repos or from
the AUR) as described in the wiki [4] and reboot to start using
SELinux.
* Second, it's possible to compile things which are disabled at
runtime. For example, I don't need to compile the kernel without IPv4
to test what breaks when running a non-IPv4 kernel, I only need to add
a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
for LSM. Even if they are compiled, they can be enabled/disabled with
such runtime configuration and this config doesn't require much work.
* Third, users who want to combine several unofficial features for
their kernel already have to do weird things. For example, I'm using a
grsec kernel with SELinux. A few months ago, there were linux-grsec
and linux-selinux in the AUR but no package which provided both. Hence
I needed to build a custom package to have both. Now, the next time
linux-grsec's maintainer will sync its config with the official repo,
SELinux will be available in this package (unless I've missed
something) and I'll no longer need to build my custom kernel.

That been said, I agree that having a kernel with less features would
be good. To my mind, here are possible ways :

a) Create a linux-light package with less features than the linux
package, and don't trim linux' configuration.
b) Rename linux as "linux-full" (as an official package) and trim linux' config.
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 environment variable [5].
d) Don't create new packages and trim linux' config (this is your
idea, if I understood correctly).

Any of a) or b) would suits fine for me if you choose to drop LSM in
the lighter config.

Regards,

Nicolas

[1] https://github.com/Siosm/siosm-selinux
[2] https://github.com/fishilico/selinux-refpolicy-patched
[3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261
[4] https://wiki.archlinux.org/index.php/SELinux
[5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Daniel Micay]

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 there are other things that have an unknown impact on
> everyone.
> 
> I want to trim our kernel down to what we actually support.

I think we should drop x32 support if no one is planning on packaging
the minimum of a compiler and standard C library. It's cool, but no one
appears to be very interested in using it in the real world. You would
probably get bigger wins from recompiling with -march=native, so I
somewhat doubt that anyone grasping for the last bit of performance will
use our binaries anyway.

This was already responsible for a security vulnerability in Arch:

http://seclists.org/oss-sec/2014/q1/187



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Thomas Bächler]

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 disabled
>>> non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels
>>> should keep Yama available albeit disabled by default (as they now do).
>>
>> Once yama is built-in, the ptrace_scope protection is enabled by
>> default. There is no option to change that.
>>
> 
> But by default, kernel.yama.ptrace_scope = 0

No. The default is 1.




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[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 disabled
> > non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels
> > should keep Yama available albeit disabled by default (as they now do).
> 
> Once yama is built-in, the ptrace_scope protection is enabled by
> default. There is no option to change that.
> 

But by default, kernel.yama.ptrace_scope = 0, which according to documentation
(Yama.txt) is like having no ptrace restriction at all, and indeed gdb/strace
work...

Best,
-- 
Leonid Isaev
GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


signature.asc
Description: PGP signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Mauro Santos]

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 drop all of them.
> 
> I agree regarding SELinux/Apparmor (it's not only userspace tools, but also
> sane application policies that are missing).
> 
> 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 by default (as they now do).
> 

If the reason for dropping support is the lack of maintained userspace
tools then tomoyo does have tomoyo-tools in [community]. However it
requires the user to manage rules creation and maintenance.

-- 
Mauro Santos



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Thomas Bächler]

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 by default (as they now do).

Once yama is built-in, the ptrace_scope protection is enabled by
default. There is no option to change that.




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[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 kitchensink. I have no problem with delivering drivers that can be
> built modular, but there are other things that have an unknown impact on
> everyone.
> 
> I want to trim our kernel down to what we actually support.

Thanks for doing this.

> 
> 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 drop all of them.

I agree regarding SELinux/Apparmor (it's not only userspace tools, but also
sane application policies that are missing).

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 by default (as they now do).

> 
> 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without
> enabling CONFIG_EXPERT. I have no idea what the impact of this option
> is, other than that it was requested in order to support some tool that
> can freeze and save single processes resume them later. I am generally
> sceptical towards options that require CONFIG_EXPERT, so I propose
> dropping this one, too.
> 
> 3) We enable tons of debug options in the "Kernel Hacking" section, many
> of which have a "small performance impact". I'd like to get rid of those
> that we don't need (I didn't go through all of them yet).
> 
> What I'd like is a discussion where people suggest more things that
> could or should be dropped, and tell me what is absolutely needed and
> why. I hope that such a discussion makes it clearer to me how I should
> proceed.
> 
> Regards
> Thomas
> 

Best,
-- 
Leonid Isaev
GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


signature.asc
Description: PGP signature