[opensuse-factory] Re: [opensuse] Re: What happened to dovecot?
On 28/11/2013 01:01, Marcus Meissner wrote:
On Wed, Nov 27, 2013 at 08:43:46PM -0800, Linda Walsh wrote:
On 27/11/2013 13:16, Carlos E. R. wrote:
Because 13.1 reinstated apparmor as installed and running by default. This was not the case in 12.3 and perhaps some versions earlier.
??? Didn't someone else mention documented problems in the release notes with apparmor? Are you saying the "new" default is to turn on a non-standard security mechanism on all machines???
Why would they do that?
It is a standard security mechanism.
It is not the Linux nor the Unix standard security mechanism. It is an "advanced" or "alternate" security system that is not selected by default when you create a new kernel.
If there are issues then we can fix them.
Since it runs at boot, you are presuming the person is able to login, and bring up some mechanism to doing that. If they find themselves locked out of their machine...they likely won't. If they have an alternate way to access the net, they still may not be able to give any useful information if locked out of machine. Certainly, if they are a new user to OS, or, worse, Linux in general, they will be completely clueless. If they have close friends they generally turn to for help, first, those friends will be less likely to be able to help them unless they already know 1) OpenSuse, and 2)app armor. That will cut off a sizable portion of their (possibly non-existent) "close support group" as well. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv * If it was ***an option**, on install -- "do you want to install the * Advanced Security Mechanism, AppArmor or do you want to use the * standard Linux security mechanism? [If you didn't understand those * terms, choose the latter]. (y/[n]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You can run "logprof" or similar and report missing things in profiles.
While I could probably figure it out, I have a computer background, but until now I'd wouldn't have known logprof would have helped me -- I won't say I haven't seen the word before, but it wasn't something I was familiar with or how to use it to get into a machine I was locked out of due to AppArmor. If the option, at install (or upgrade time) was offered -- then they can take can take responsibility and, at least, know they installed a non-standard security system that isn't the default linux security mechanism. But if they are expecting a basic-linux install, I'd find a default installation of apparmor, to be like installing a Greek-font and language interface for the default installation -- sure, you could call them standard, in Greece (maybe), but it doesn't seem like a wise choise for new users OR users using the older (or perhaps a different) model. It violates the premise of "least surprise". None of this should be taken as a reflection on Apparmor being good or bad, just that it's something else that might go wrong, that, if it isn't configured "perfectly", will cause odd and random symptoms of programs being able to start, but access no resourses (like happened to the OP)... In order to create an experience with fewer unpleasant surprises (or surprises of any kind), I wouldn't *enable* (might install), AppArmor as a default. Same with "rtmond" -- installed, sure. But for a personal computer with only 1 user... I would question the need for such a mechanism as enabled by default. *cheers*, Linda p.s. -- NOTE -- in GENERAL, configuring packages to be ON by default if if they are installed, is a troublesome behavior. I see many things at install that I'd like to *try*, but usually 1 at a time. I'd prefer many things (if not most) to be "chkconfig'ed off" or whatever equivalence the SW has, by default on install (except for basic services needed to run the system). Might even have a "configcheck service" -- like the rpmconfigcheck, that checks for installed but unconfigured or disabled (have never been enabled) services -- and given to users on a list, so they can go down the list and configure & check out each of the new options. For me, I'd find such much better than the -- "we tried to set things up based on our test systems in Laos, and we had no complaints"...;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 28, 2013 at 5:15 PM, L.A. Walsh
On 28/11/2013 01:01, Marcus Meissner wrote:
On Wed, Nov 27, 2013 at 08:43:46PM -0800, Linda Walsh wrote:
On 27/11/2013 13:16, Carlos E. R. wrote:
Because 13.1 reinstated apparmor as installed and running by default. This was not the case in 12.3 and perhaps some versions earlier.
----
??? Didn't someone else mention documented problems in the release notes with apparmor? Are you saying the "new" default is to turn on a non-standard security mechanism on all machines???
Why would they do that?
It is a standard security mechanism.
--- It is not the Linux nor the Unix standard security mechanism. It is an "advanced" or "alternate" security system that is not selected by default when you create a new kernel.
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. No security mechanism can be off by default on a distribution. That's nonsense. That only protects niche users. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
Hello, Am Donnerstag, 28. November 2013 schrieb L.A. Walsh:
It's never been on by default before.
I'm sorry to disappoint you, but you are wrong ;-) Yes, there were one or two releases without AppArmor installed by default, but before that it has been installed and enabled by default since Novell bought Immunix in 2005. To get back on the more productive part - I'm aware of the problem and already working on updating the profiles. You can download the latest dovecot profiles from https://bugzilla.novell.com/show_bug.cgi?id=851984 (comment 8 includes a tarball) - feedback on them is more than welcome.
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.
Unfortunately "secure" is not black and white - even if you think your system is secure, I'm quite sure it has some yet unknown bugs that could be exploited. Therefore it's always a good idea to have additional security added.
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.
As you might have noticed, most existing AppArmor profiles are for daemons (syslog, dovecot, samba etc.). Most of them need to have open network ports, so it's a bit more than "don't let other people log onto your computer". Today's attackers often come in over the internet. I fully agree that you can make a mail server much more secure by removing the network cable (and disabling wireless) - but such a mail server wouldn't be too useful ;-) Regards, Christian Boltz PS: For additional security, remove all cables from the server, dig a deep hole in your garden, put it into the hole and fill up the hole with concrete ;-) -- Ich bin beeindruckt! Windows startet nicht mehr -> Problem gelöst. Ich wünschte, ich könnte meine Probleme auch so befriedigend lösen. [Sandy Drobic in suse-linux] -- 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 Fri, Nov 29, 2013 at 3:20 AM, L.A. Walsh
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.
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.
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.
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. 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. 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. 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.
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,
Ehm... no, not saying that. Not even close.
or you are saying That the existing security mechanism = no security and that linux has never had any security until apparmor arrived.
Neither that. Though closer.
Um...I don't think your statement makes sense.
Whatever. We have a saying. No hay mejor sordo que el que no quiere oír.
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.
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. Security isn't an individual thing.
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.
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 -- 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 Fri, Nov 29, 2013 at 6:34 PM, L.A. Walsh
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.
Shorewall is an iptables frontend. I don't see how that makes iptables not a firewall.
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. If there's a malfunction (or misconfiguration), filing a bug report is what's needed. In any case, turning it off isn't.
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.
Pre-configured and off leaves the majority of the install base unprotected.
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.
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.
Well, it's a tradeoff. Security of oblivious users wins IMNSHO.
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? ;-)
As always in security, you're quite naive[0] (I just googled that, I make no claims about its content). 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.
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.
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. 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.
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.
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. [0] http://www.itworld.com/security/77499/first-linux-botnet -- 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 Fri, Nov 29, 2013 at 9:14 PM, L.A. Walsh
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?
Mind you, SELinux and AppArmor are both quite standard. You may not know which one is on, but they are quite standard nowadays. And, if you read the release notes for 13.1, section 5.11. AppArmor and Permission Settings, you'd know. -- 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
On Fri, Nov 29, 2013 at 11:45 PM, L.A. Walsh
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.
On Fri, Nov 29, 2013 at 11:45 PM, L.A. Walsh
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".
Are you implying you're a victim? Hey... if you don't want to learn, fine with me. I'll just shut up then. -- 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
On Sat, Nov 30, 2013 at 8:28 AM, Carlos E. R.
-----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 installed from netinst and remember seeing it, you know, just after testing the internet connection and fetching the "latest release notes". I may try again with the latest ISO just in case. -- 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
On Sat, Nov 30, 2013 at 5:48 PM, Carlos E. R.
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.
Shouldn't the interne site have the newest ones? -- 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
On 11/30/2013 11:43 AM, Claudio Freire wrote:
On Sat, Nov 30, 2013 at 8:28 AM, Carlos E. R.
wrote: 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 installed from netinst and remember seeing it, you know, just after testing the internet connection and fetching the "latest release notes".
I may try again with the latest ISO just in case.
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. Also the case, though are presenting pertinent release notes, rather than all in 1 file. I.e. seeing changes for 'core' or 'base' installed products in 1 place and separate from kde/gnome/<favoriteapp>... would be more useful to what I am installing. Note. I am saying this from the point of view of someone familiar other linux distros, say, and trying opensuse for the first time in 13.1. (To be clear, this problem doesn't usually, directly affect me, as I usually run a vanilla kernel w/o the optional security models). -- 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
participants (4)
-
Carlos E. R.
-
Christian Boltz
-
Claudio Freire
-
L.A. Walsh