Lars M������������������������ wrote:

On Fri, Mar 08, 2013 at 06:20:02PM -0800, Linda Walsh wrote:

...

Sorry, ...

Probably should be fixed before 12.3 ships...

Fortunately, the fix is easy -- just remove the offending patch:

bash-3.2-longjmp.dif

a) Please consider to add the patch to bnc#806628

b) In general if you believe a defect has security implicationsissue please select 'Component: Security' to enable access limitation in bugzilla.

Cheers,

Lars

Setting component:security doesn't enable access limitations. On the bug you set component:security on, I was able to access it without logging in. On the new bug I created I had set the 'open-only-to-suse-security' flag, and it that flag only allowed access to the bug after I had logged in (presumably because I was the reporter). As for 'a', above, are you asking me to copy the source of the patch that is from the suse rpm, that is in the file 'bash-3.2-longjmp.dif' into the bug report? It is already part of the suse bash rpm. By patching the rpm, suse has introduced a security hole that is specific to suse's version. I'm sorry, I guess I was trying to be a bit too circumspect in reporting the details and was too close to them, myself, to not be aware that others would know what I was talking about. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner wrote:

If you _create_ it under that Component it will get stricter permissions.

--- That is not clear from the bug interface. What is clear is the tick-box at the bottom that says to make the information only available to suse-security. Classifying something as security relevant doesn't mean it is a security vulnerability. Clicking a 'sensitivity' box to indicate that it is sensitive is pretty clearly indicating it is sensitive -- not just something to do with security. 2nd prob. When I first filed the bug, a few weeks ago, the security implications were not clear.

The rbash angle was not clear yet, but I am not sure it is real either.

If a user is running under 'rbash', and a SuSE-only patch always switches that to /bin/sh (ignoring the shell the user is running under), you can be certain it is a problem. It was tested.

Either way, the bash maintainer and we will take a look when we get to work on Monday.

--- The original problem (without the security implications) was reported over a week ago, with my concerns being brushed off with justifications for why a 5 year old patch against a much older version of the product should be kept -- because it might protect against some future problem. That logic is a reason for never removing any patch and is IMO, bad practice. It certainly isn't the only instance of such. I thought you guys were generally *at least* as knowledgable (usually more so) about these products. (I am serious... I don't usually assume the other people are stupid -- more often, I assume they know their product better than me, because it is their product (that an usually I'm told that I don't know what i'm talking about...;-))... Just like the business with "App compat between versions of OpenSuse (specifically related to perl, but including others)," where I fought to keep a bug from being closed as invalid. It it was important for me to do so, I could find security sensitive issues related to suse choosing not to go with upstream defaults and going with special patches and new, untested features. Suse doesn't even test their products anymore on loaded production systems, because it shows up too many problems. That's all but guaranteeing not only problems, but a higher-than-normal security-vulnerability rate as security vulnerabilities are proportional to bug count and inversely proportional to amount and complexity of testing. But such statistics are well known in the field, and I have presumed that the people choosing sterile build & test know the security implications of doing such. Telling customers in the field that their config isn't supported is scant comfort if they've been subject to a security vulnerability due to known, increased security risks of the current development model. *At* least, I know the risks -- if I was paranoid enough, I'd be running BSD, not linux. It's also the case that there is a tradeoff between user-friendliness and functionality vs. higher security. I've chosen Suse for over 10 years, despite knowing that my computer would be safest, enclosed in several feet of cement -- but it's really hard to use that way... ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org