On 11/28/2013 1:13 PM, Claudio Freire wrote:

Standard or not, it's the kind of security mechanism that takes so much effort and knowledge to properly set up, that it HAS to be set up by the distribution, and by default, to be of any value.

Then why are firewalls 3rd party applications? They can be just as hard to configure. Besides, I didn't say unconfigured and uninstalled. I made a clear distinction to have it setup, but allow changing the standard to be a choice made by the user. Even if it was as little as a question during setup -- so they made a positive choice to choose the non-standard security policy -- that would be enough. So are you saying, or do you believe that if you don't force the security policy on users, it won't be of any value?

No security mechanism can be off by default on a distribution. That's nonsense. That only protects niche users.

It's never been on by default before. Why does it HAVE to be on now without user input? Either you are saying no one wants it because it has only had niche testing and you need the opensuse community as guinea pigs to get the testing done more than to 'niche' level, or you are saying That the existing security mechanism = no security and that linux has never had any security until apparmor arrived. Um...I don't think your statement makes sense. SELinux is built-in by default. If they want SELinux, has it been tested with AppArmor? There's also the Biba+Bell La-Padula security models embodied in Smack. It has had the benefit of being a tried and true method for DOD machines since the 80's. (FWIW, MS added something similar to the Biba model to NT in Vista -- their 'Trusted Installer' at the most trusted and Low-trust for internet shielding -- where lower privileged process can't write to higher integrity data stores. As for it possibly only protecting niche users -- maybe only niche users need that level of protection -- vs. the accompanying problems of programs not working. Generally, you don't let other people log onto your computer. If they have gotten that far, that's bad. AppArmor, is more for internal threats initiated from the computer on parts of itself. That type of security policy might be more useful in protecting computers FROM the USERS... Turning it on by default, certainly indicates an unwillingness to even give users a choice of what security mechanisms they want on their computer. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-29 07:20, L.A. Walsh wrote:

It's never been on by default before. Why does it HAVE to be on now without user input?

False. There was a time when apparmour was named "Novell Apparmour". It was the star of the crown. Novell was proud of it and apparmour active was the default at that time. And a very good thing it was. Much later, the group of developers were fired, reason unknown. They continued on their own, and the product was hosted at Ubuntu. After some time, it became low profile in openSUSE and it was not activated by default. Now we have it back, and I happily welcome it. Unfortunately, the apparmour yast modules have bitrot, some have even disappeared. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKYlNQACgkQtTMYHG2NR9XnAQCdFy3QCw65+vtDNm+IErCdUPvM tQ0AnjlCHRy/8qXpvloCVKzGdnNrUwMP =UrIs -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/29/2013 9:00 AM, Claudio Freire wrote:

On Fri, Nov 29, 2013 at 3:20 AM, L.A. Walsh wrote:

...

On 11/28/2013 1:13 PM, Claudio Freire wrote:

...

Standard or not, it's the kind of security mechanism that takes so much effort and knowledge to properly set up, that it HAS to be set up by the distribution, and by default, to be of any value.

---

Then why are firewalls 3rd party applications? They can be just as hard to configure.

They're not. Linux firewalls live in the kernel, and default linux installs (especially openSUSE) have included properly configured firewalls for years. Maybe you're thinking windows.

Sorry, firewall != packet routing. The kernel has packet routing. It's not until it is configured to selectively reject or drop packets that it becomes a firewall. Maybe you are forgetting, for example, shorewall? There've been others before that.

Well, firing up yast and turning it off isn't rocket science, but sure, an option somewhere on the advanced install procedure couldn't hurt.

How would they know it is on or where to go to turn it off if they were new to OpenSuse?

...

So are you saying, or do you believe that if you don't force the security policy on users, it won't be of any value?

Pretty much.

Um again, difference between installing it on, or installing pre- configured & off.

Ie: regular users, and that includes many developers, anyone not specialized in linux security in fact, don't really know how to configure something like AppArmor or SELinux, and if they know, they don't want to have to spend the time to do it on every installation.

Well, firing up yast and turning it ON isn't rocket science...

For the ones that do not know, having it on by default is a necessity, since they won't even think of turning it on. And those are probably over 90% of the target audience.

For the ones that do not know opensuse has a non-default security, they won't even know what to turn off, let alone where.

And in this field (security), statistics matter. Securing 1% of the target audience is worth nothing, well, unless that 1% happens to work on a nuclear reactor or something critical like that. But having a good chunk of the install base vulnerable just encourages botnet proliferation, and that's a problem for us all.

Documentation? Botnets have not been a problem on Linux -- especially those configured with firewalls. Maybe you are thinking Windows? ;-)

...

SELinux is built-in by default. If they want SELinux, has it been tested with AppArmor?

SELinux and AppArmor were developed in parallel IIRC, ie: they're two technologies with the same aim.

I don't think they're exclusive technically speaking (ie: with a lot of love they could be made to work together), but I do believe they're not intended to coexist.

...

There's also the Biba+Bell La-Padula security models embodied in Smack. It has had the benefit of being a tried and true method for DOD machines since the 80's.

I wouldn't use them as role models. Nor the others you mention.

Does apparmor support chksum based rules, or path only?

...

As for it possibly only protecting niche users -- maybe only niche users need that level of protection -- vs. the accompanying problems of programs not working.

Most common error of those that don't know about security.

The most common error of those who think they know about security is that they know about how to help everyone else.

Security isn't an individual thing.

First thing many product vendors could get right is to not assume they know what is best for all users. Only notable problem I had with a mixed linux/Windows environment, was the linux sendmail being misconfigured upon upgrade to stop enforcing my access list. It was caught before much damage happened, but apparmor wouldn't have helped because it was right after an upgrade and no baseline for the new apps had been set, so any new rules that were needed would likely have been missed in setup-related approvals.

...

Generally, you don't let other people log onto your computer. If they have gotten that far, that's bad. AppArmor, is more for internal threats initiated from the computer on parts of itself.

Nope, AppArmor is for damage contention. WHEN some of your apps' security gets breached, AppArmor stops it from spreading harm.

--- If one app, inside your perimeter loses protection, isn't it stopping the spreading by putting up a wall between apps on the same computer? -- i.e. what is now an internal threat initiated internally (from the compromised app) upon other parts of your computer or network?

...

That type of security policy might be more useful in protecting computers FROM the USERS... Turning it on by default, certainly indicates an unwillingness to even give users a choice of what security mechanisms they want on their computer.

FUD

--- So making things clear and apparent to users is FUD, while doing things without their consent is fine? You got FUD backwards. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/29/2013 2:14 PM, Claudio Freire wrote:

Shorewall is an iptables frontend. I don't see how that makes iptables not a firewall.

--- Iptables are a load of bricks. What you build with it is entirely based upon configuration. Unconfigured, iptables does nothing. The firewall functionality is entirely based in how you configure it.

...

...

Well, firing up yast and turning it off isn't rocket science, but sure, an option somewhere on the advanced install procedure couldn't hurt.

---

How would they know it is on or where to go to turn it off if they were new to OpenSuse?

Barring malfunction, if they don't know, they don't need to.

--- Two strikes -- we've already had a malfunction which is what the base note was about. And second on principle. SW always has bugs, especially lightly tested or untested SW.

If there's a malfunction (or misconfiguration), filing a bug report is what's needed.

--- No. I've filed many bug reports and had them thrown in my face as my "whatever" policy not being supported. They make any changes in the firewall, they'll be likely told it isn't supported. This also goes back to them having the knowledge you assume. You assume they know the cause, you assume they know how to file bugs, you assume they are even CAPABLE of filing a bug. I doubt my parents would have the first clue.

In any case, turning it off isn't.

--- Simple beats complex.

...

Um again, difference between installing it on, or installing pre- configured & off.

Pre-configured and off leaves the majority of the install base unprotected.

This is after they've been asked at install time if they want it or not -- you are assuming the majority picks to not install it. If that is the case, you are forcing your protection mechanism on them. You are providing a good reason for not doing any automated installs or upgrades, nor using a OS built kernel. If they don't know about it, it won't hurt them. That is a very bad precedent.

...

...

Ie: regular users, and that includes many developers, anyone not specialized in linux security in fact, don't really know how to configure something like AppArmor or SELinux, and if they know, they don't want to have to spend the time to do it on every installation.

---

Well, firing up yast and turning it ON isn't rocket science...

Only if it comes pre-configured. Otherwise, it is, since it implies building the profiles.

Pre-configured and "by choice" is how suse firewall was configured for years. I wouldn't call that worthless.

Well, it's a tradeoff. Security of oblivious users wins IMNSHO.

The basis of a a people-ruled government is that the people are informed. You are making it clear that you are for a "benevolent dictator" approach. The ends justifies the means. Historically, that has not turned out well.

As always in security, you're quite naive[0] (I just googled that, I make no claims about its content).

As always? Proof? Evidence? Claims w/o proof are commonly called marketing, advertising or propaganda. Anecdotal evidence is not a representative sample.

If that were the case, it'd only be because security in linux is taken seriously and by default. What you propose (making it off by default), is the exact opposite.

--- If it has always been taken seriously, then you are saying AppArmor wasn't needed.

No, no, AppArmor wouldn't have helped because the kind of behavior it prevents isn't one that resembles sendmail's primary function so much (ie: sending mail). AppArmor wouldn't have even noticed anything weird.

It doesn't do port policing by app?

BUT, if the bug had been more serious, and it had allowed remote code execution, AppArmor WOULD have prevented someone from installing a rootkit in your computer and gaining root.

Only if apparmor was configured correctly. If they can't keep a working configuration working on upgrade, how likely is it that they'll get a 100% perfect apparmor installation?

...

...

FUD

---

So making things clear and apparent to users is FUD, while doing things without their consent is fine? You got FUD backwards.

I'm all for making things clear.

Not for disabling AppArmor by default. If anything, quite the opposite. I suggest it should be kept on by default, and with profiles for as many applications as possible.

And if a prompt is added to the install procedure, it has to state clearly that if in doubt, leave it on.

That would be fine -- I just said it needs to be made clear at install time that a non-standard security policy is being turned on and that not doing so is bad practice (unless you are trying to be microsoft...?) Next up? Trying to be Sony with a rootkit install for the user's own good?

[0] http://www.itworld.com/security/77499/first-linux-botnet

Yippee.. anecdotal evidence is irrelevant. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/29/2013 4:31 PM, Claudio Freire wrote:

...

That would be fine -- I just said it needs to be made clear at install time that a non-standard security policy is being turned on and that not doing so is bad practice (unless you are trying to be microsoft...?) Next up? Trying to be Sony with a rootkit install for the user's own good?

Mind you, SELinux and AppArmor are both quite standard.

==== The default security policy is *standard*. The others are not built unless you choose optional security models. From the kernel configuration Kconfig file: choice prompt "Default security module" default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX default DEFAULT_SECURITY_SMACK if SECURITY_SMACK default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR default DEFAULT_SECURITY_YAMA if SECURITY_YAMA default DEFAULT_SECURITY_DAC --- if nothing is chosen, DAC, which has been the only "standard" security policy (in terms of it being most widely deployed or used). That doesn't mean it is the best --- determining that is based on your needs. Thinking that 1 of the above fits "all"; is better for everyone; and should be made the default w/o user input is seems to be a perfect fit for the word "hubris". ([http://en.wikipedia.org/wiki/Hubris]).

And, if you read the release notes for 13.1, section 5.11. AppArmor and Permission Settings, you'd know.

And those are displayed during the install flow, where? I seem to have missed where they are displayed before installation. Under Hubris, it is mentioned that it is associated with "shaming the victim", like inferring that they "should have done something", or making statements like: "As always in security, you're quite naive". AFAIK, they are not part of the install flow (not that people generally read long lists of notes when they just want to install it and have it "work") -- which, if it did, the OP would never have posted. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-30 05:58, Claudio Freire wrote:

On Fri, Nov 29, 2013 at 11:45 PM, L.A. Walsh wrote:

...

...

And, if you read the release notes for 13.1, section 5.11. AppArmor and Permission Settings, you'd know.

--- And those are displayed during the install flow, where?

Yes

...

I seem to have missed where they are displayed before installation.

You seem to.

She is right on this point. The notes are displayed, but the old and obsolete version. You can see for yourself at http://doc.opensuse.org/release-notes/x86_64/openSUSE/13.1/ https://www.suse.com/releasenotes/i386/openSUSE/13.1/RELEASE-NOTES.en.html https://www.suse.com/releasenotes/x86_64/openSUSE/13.1/ that the version is dated on October, and that they contain no reference to apparmour at all, no section 5.11. This is Bug 852174 and Bug 851864. To see the current release notes you have to install the system, then update it, then display the file "/usr/share/doc/release-notes/openSUSE/RELEASE-NOTES.en.html" (or the translation if you prefer). I can not understand this delay. It is causing several people to bump into problems while installing or upgrading, ask baffled in forums or lists, and then be told to read the release notes - and finally, be told that to read them he needs a working 13.1 system. And the helper be sorry for telling to RTFM. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKZy8gACgkQtTMYHG2NR9WwoQCdEy4YQzZn3tpjp8SXE5gNIc9+ XuYAoI/bmQ5cCSQQsHSvl1AmkBi73hR7 =pBVE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-30 20:43, Claudio Freire wrote:

On Sat, Nov 30, 2013 at 8:28 AM, Carlos E. R. <> wrote:

I installed from netinst and remember seeing it, you know, just after testing the internet connection and fetching the "latest release notes".

It depends where the installer reads the notes from. If it fetches from the internet site, they are the old version. If it fetches from the just installed version, there is a difference with netinstall and standard: netinstall considers the update repo, but standard install depends on the user choice. Me, I never fetch the updates at install time, so I don't see the newest notes version. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKaTzoACgkQtTMYHG2NR9UOlgCff3aVclBOzuBQQzGmI9MB1WKI 8qEAnjb72lFFghsaTSnPcuOavvc+IoIQ =OGjT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-30 22:21, Claudio Freire wrote:

On Sat, Nov 30, 2013 at 5:48 PM, Carlos E. R. <> wrote:

Shouldn't the interne site have the newest ones?

It just does not, that's what the Bugzilla is about. I have emailed several people, to no use. Nobody seems to be responsible or know who can update that page. 13.1 has been released ages ago, yet the published on the web release notes are obsolete. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKaXjoACgkQtTMYHG2NR9X1+wCeOj4ztWM4768rxrU2mMmNFimw F2YAnR4whEHFagdhUCHOgHK+IV9/GSP6 =BZJj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-12-01 00:10, L.A. Walsh wrote:

On 11/30/2013 11:43 AM, Claudio Freire wrote:

...

On Sat, Nov 30, 2013 at 8:28 AM, Carlos E. R. <> wrote:

It has been my experience that Release Notes have usually been made available AFTER installation. Vs. README's, and 'CHANGES' (or "whatsnew") came in viewable form before the install -- If they were available.

I've only ever seen release notes after installation.

The translator team hurried to have the final version of the translation notes ready before release. They were ready, I saw them. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKad+YACgkQtTMYHG2NR9VZawCdF7jYRPCS3O1hG5DDP4yDsLJt uboAn0fEkObhM/3v8ua8NcOOEbJfIGXa =FV0S -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org