Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting
Mailing Lists: lists.debian.org > debian-user-digest > 07 > 070219.html (Request Expert lists.debian.org Support)

debian-user-digest Digest V2007 #2040

From: <debian-user-digest-request(at)lists.debian.org>
Date: Fri Jul 27 2007 - 12:33:48 EDT


Content-Type: text/plain

debian-user-digest Digest Volume 2007 : Issue 2040

Today's Topics: 

  Re: why do iceweasel et al have more  [ Erik Persson  ]
  Re: minimal firewall computer         [ "Ari Constancio"  ]
  Imagemagick                           [ "Sridhar M.A."  ]
  Re: searching for graphical torrent   [ Owen Heisler  ]
  Re: Imagemagick                       [ Florian Kulzer  ]

Date: Fri, 27 Jul 2007 15:54:27 +0200
From: Erik Persson <erik-maillist@djingis.se> To: debian-user@lists.debian.org
Subject: Re: why do iceweasel et al have more frequent security issues? 

Message-ID: <46A9F913.2070106@djingis.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Sackville-West wrote:
> On Fri, Jul 27, 2007 at 04:49:41AM +0200, Erik Persson wrote:

>> Andrew Sackville-West wrote:
>>> On Thu, Jul 26, 2007 at 10:52:07PM +0200, Erik Persson wrote:
>>>> Anyhow, the basic fact that there is fewer security alerts in Konq makes 
>>>> this a more secure browser, whether this maybe is because only of a 
>>>> smaller user base or not.
>>> I'm sorry, and i hate to argue with people, but this last statement
>>> just doesn't fly with me. security alerts are the result of someone
>>> finding a security problem and reporting it. The fact that fewer
>>> security alerts exist does _NOT_ mean that konq is more secure. It
>>> only means it has fewer reported security problems. Now it _could_ be
>>> that this is because there actually _are_ fewer security problems, but

Do you need help?X

>>> it could _also_ be because no one has _found_ or reported
>>> problems. There's an important distinction there.  
>> The assumption is of course that there is no significant difference in the 
>> ratio of reported security issues to discovered security issues, and I 
>> can't see any reason those should differ.

>
> I can't see any reason why they _should_ differ either, but it is
> entirely possible that they do and that's the point.
>
> It boils down to this argument you stated:
>
> "Anyhow, the basic fact that there is fewer security alerts in
> Konq make this a more secure browser...."

Yes. You argue that there is no security advantage of a browser having fewer security alerts, and the difference is all because a larger user base. However, the larger user base that is leading to more found security flaws also makes the browser a more interesting target for attacking.

>
> and that's ridiculous. It doesn't make it a mroe secure browser. It
> makes it a browser with fewer reported security alerts. period. There
> _may_ be other issues involved and it in fact _may_ be a more secure
> browser, but that is not necessarily because it has fewer alerts.

Do you need more help?X

There may be, but if you don't know you can't say there is. And even if there were such asymmetry you don't know which browser it would favor. (The assumption that there is fewer reported security flaws in konq really makes the existence of such asymmetry more likely in absence of other facts, but it does not "consume" the whole advantage of konq - see below. On the other hand, current experience doesn't favor the explanation of differences in the ratio of reported to found security issues).

> The relationship between reported bugs in one piece of software versus
> another is directly related to how many of those bugs have been found,
> not how many bugs there are. True, there is a relationship between the
> number found and the number that exist, but that doesn't mean that
> because one has fewer reported bugs that it has fewer bugs. That is,

Well, why not?

> the number found will always be equal to or less than the number that
> actually exist. But that is all you can know about the number of bugs
> in a piece of software -- it has exactly or more than the number
> reported. One piece of software could have 1000 bugs with one reported

No. You are arguing about asymmetry again. As I said, you don't know of any asymmetry, and you don't know in which direction it goes, and you can't argue that it consumes the whole difference.

> while another piece could have 100 bugs with 99 reported. According to
> your statement, the software with the 1 reported bug has fewer bugs
> than the one with 99 reported but that's not necessarily true.

Well it is not necessarily true, but it is likely to be true. 

>> Anyhow, it is more likely that a browser with more reported security issues 
>> have more discovered security issues. And it is also more likely that a 
>> browser with more discovered security issues have more security issues. 
>> Both, of course, under the assumption that there is no information that 
>> changes this.

>
>
> yes yes yes... _likely_ sure... given a reasonable assumption that the
> number of users, testers and coders involved are sufficient to
> effectively test the software, then yes, the one with more reported
> issues _may_ be less secure. But that's not what you said. You said
> the fact that Konq had fewer reported problems makes it more
> secure. You didn't say likely, or reasonable assumed to
> be... important distinction.

Since we don't know the true number of security flaws in any software, we can only make assumptions. I though that was sort of an axiom when discussing security flaws in software.

Can we help you?X

I said:
"If there are fewer security alerts with Konq the only reasonable conclusion, if you don't have strong facts pointing the other way, is that Konq is more secure, and that this is partly because of better code."

The sentence you cite comes from the fact that it is likely that, whatever the reason is for the fewer reported security flaws in konq, the number of security flaws in konq that the hackers are finding (and not reporting) are likely fewer, and that those hacker found flaws likely are related to the number of reported flaws.

Compare to os x. There have been some rather severe security issues with os x, but I haven't heard of any exploit in the wild.

> 

>>> WARNING! CAR ANALOGY!
>>> if we have two cars parked side-by-side and mine is stolen (I'll
>>> take the fall for this analogy ;) and yours is not, does that mean
>>> that your car is more secure? no. it means someone looked for a way
>>> into my car and exploited it. maybe they never even looked at your
>> It also mean that it is more likely that your car is less secure.

>
> ...
> 
>> If you have 10 cars of type A and 5 of type B and 2 A cars, and one B car 
>> was stolen, you should guess, if no more information was available, that 
>> the cars were about equally secure. No, if you have 10 A cars, and 5 B 
>> cars, and 1 A car was stolen and 4 B cars, you should guess that the B cars 
>> were less secure.

>
> no. you _could_ guess that. But it is equally valid to guess that car
> B's, being rarer cars are more desireable and therefore more likely to
> be stolen.

Well, If you don't have any information, you *should* guess that the car type with the larger proportion of stolen cars is less secure. It is the logical conclusion. It does however not EXCLUDE other reasons. You should also for example guess that the car type is more desireable, etc etc. The thing is, without information you can't discriminate between different reasons, you could only say that all reasons that makes the car type have a higher ratio of stolen cars are more likely. The fact that you have a result, makes all reasons increasing the likelihood of this result more likely. 

>> Now, if you have x A cars and y B cars and you don't know x and y, but you 
>> know that more A cars are stolen, it is more likely that the A cars are 
>> less secure, since there is no reason to believe that x
>> is larger than y, than believing the opposite.

>
> no, again, you could believe that, but its equally valid to believe
> that A cars getting a high price in the chop-shop market. There is

Well, no. If you don't know you can't discriminate between reasons. You should thus *also* believe that A cars are more desireable. One does not exclude the other. However since we don't know we have to guess that all reasons making car type A more stolen also are more likely than the opposite or the equality between the two types. 

>>> END CAR ANALOGY!
>>> a more pertinent fake example.
>>> programmer X finds a security hole in konq that when visiting a

Can't find what you're looking for?X

>>> carefully crafted website, allows remote execution of code, privilege
>>> escalation and ultimately results in a box getting
>>> rooted. okay. that's obviously a security problem. but programmer X
>>> doesn't report this problem and no security alert is issued.  programmer Y 
>>> finds a security hole in mozilla that allows an already
>>> installed plugin at a certain version to escalate its own privileges and 
>>> as a result
>>> download and save a piece of code to disk with the name
>>> "execute_me". Now if the user happens to see that file and thinks,
>>> hmmm... I wonder what that is and executes it (after chmod +x) it does
>>> a rm -rf on their home. programmer y reports this security hole and a
>>> security alert is made detailing the problem. now, clearly, the konq 
>>> vulnerability is *much* more of a security risk
>>> than the mozilla error, right? the mozilla one requires the plugin be
>>> already installed and the right version and then requires the user to
>>> actually chmod and execute the thing. the konq one just requires the
>>> user to visit a carefully crafted website. 
>> If this would be the case in the mozilla vs konq situation, you have to 
>> explain to me why:
>> 1) konq security issues should be reported at a lower ratio

>
> because the person who found the bug likes knowing the bug and wants
> to be able to utilise it to compromise machines, and thus keeps it
> under his black hat...

We are not talking about a single case here. We are talking about the statistics of reported flaws. If your example should have any impact on the real firefox vs konq case, you have to make it likely that there exists such a bias in the total statistics of reported bugs and **especially** that this bias explains the whole observed difference. 

>> 2) why security issues in konq are more severe

>
> it was an example showing how your premise that more reported
> bugs means less secure. I was showing that the number of reported bugs
> is not necessarily related to the security.

IF it should have any impact at all on the number of reported bugs you must make it likely that there exists such a bias in the real case and **especially** that this bias is reason to believe that there is no security difference.

Don't know where to look next?X

> 

>> eg. why there should be reason to believe that there is a statistically 
>> significant bias between the browsers in factors such as reporting security 
>> issues and severity of security issues.

>
> because the whole conversation was predicated on the possibility that one
> browser has significantly larger mind/eye-share and therefor has greater
> opportunity to have problems discovered and reported. Sure there are
> some folks looking at fire&iceweaselfox and hiding the vulnerabilities
> they discover, but as the crowd of users/testers/coders grows, they
> become statistically less significant than they would be for a program
> with lower numbers of users/tester/coders.

You have to explain why this should "consume" the whole reported advantage of konq. 

>> I can see no reason to believe one or the other. I just look at the facts - 
>> there are less security issues reported for konq. The only reasonable 
>> conclusion is that konq is more secure.

>
> no. that is _a_ reasonable conclusion, but by no means the only one.

It is not a reasonable conclusion that konq is less or equally secure, since we lack other facts. This is what I mean by "only". 

>>> but based on what you've written above, because the mozilla one was

Confused? Frustrated?X

>>> reported, then mozilla is less secure than konq. that doesn't add
>>> up. And in fact, in my fake example above, the lack of security alert
>>> makes konq even more of a security problem because 1) the right devs
>>> might not know about the problem to issue a patch and 2) the public
>>> doesn't know about the problem to avoid it until a patch comes along.
>> As I stated above, you have to explain how this constructed example could 
>> have any impact at all on the real mozilla vs konq case.

>
> I don't have to explain it because it doesn't. it was an example used
> to illustrate how your assertion was false. But in fact, I believe
> that in fact this sort of thing goes on all the time. An unreported
> security vulnerability is _much_ more dangerous than a reported one. A
> reported one gets fixed. An unreported one gets exploited.

Of course. But you don't know any of this. You know that there is fewer reported sec issues in konq. This is reason to believe that konq is more secure (as well as any other reason giving this result).

You don't know if the security vulnerabilities that are found in konq are reported to a lesser degree, and especially you can't argue that such a difference "consumes" the konq advantage. 

>> As I said, if it is a fact that there is fewer security alerts in konq, the 
>> only reasonable conclusion is that konq has less security issues.

>
> nope. konq has fewer security alerts == fewer reported security
> problems !== fewer actual problems.

Wrong.

>
> 

>> All other 
>> conclusions rely on some sort of asymmetry between the browsers, for 
>> example when it comes to the severity of the reported security issues, the 
>> presumed not found or not reported security issues, in the the ratio of 
>> reported found security issues etc.

>
> But these are all valid possibilities, not certainties. You have
> stated that this:
>
> fewer security alerts == fewer security problems
>
> is a certainty. Or at least near enough so as not to be significant.

Yes, it is significant.

Call Pantek today for Open Source Technical Support at 1-877-546-8934 - 24/7/365X

It is also what seems to be the normal way of viewing things when it comes to reported security flaws. Sendmail is believed to be more unsecure than postfix since sendmail has a larger number of security issues in the past. Windows is believed to have more security issues than openbsd since there have been a larger number of security issues in windows etc etc etc etc etc. This is of course not an argument but merely an observation.

> But its not a certainty. It may, in the final analysis be true, but
> until _all_ the security problems from both programs have been found
> and counted, then it is not a certainty. It is unknowable.

We are not talking about likelihoods of 1 here. We are talking about what is more likely, especially since we *never* can no if all security flaws have been found in a software of reasonable size.

If you were to argue the way you do, you could *never* no if one product is more secure than another. 

>> If you don't have any facts supporting such kind of asymmetry, you can't 
>> argue that there exist such asymmetry, and especially you can't argue that 
>> such asymmetry is to the advantage of Firefox (it could just as likely be 
>> to the advantage of konq - if it existed).

>
> I never argued that there _was_ such an asymmetry. I provided an
> example of how such an asymmetry would make your assertion false.

Yes, but if this would be interesting, you also needs to make this argument "consume" all the advantage of the lesser number of reported security flaws in konq.

> Note that I have no bias regarding kong and iceweasel.
>
> Also, I'm more than willing to embrace a counter example. OpenBSD has
> had two remote holes in the base install in more than 10 years. And
> I'm willing to wager that it is in fact probably the most secure OS
> out there for common folk to use. BUt that is a special case because
> we _know_ that it was built up piece by piece for one purpose -- to be
> secure. Security has motivated every decision made about OpenBSD so we
> have additional data on which to make the assumption that its number of
> reported vulnerabilities is a good indicator of its security
> overall. But just pulling two pieces of software out of the air and
> comparing their security based on the number of reported
> vulnerabilites doesn't work. Not without some additional information
> to support those assumptions.

It does. As I said, if you have a result, all explanations making the result more likely, are more likely. If you don't have any facts making one or more explanations more likely, you can't discriminate between them. Take for example the simple, but not equivalent, case of getting 4, 5 or 6 when rolling a dice. If you know you got a 4,5 or 6 (but not which of them), this increases the likelihood that you got a 5, even if it is also increases the likelihood that you got a 6 or a 4. You can't be sure you got a 5 though. If you know that the 4 or 6 are favored, this *could* consume the whole increased likelihood that you got a 5, but if you don't know you can't tell.
If you have a strong indicator of security, as the number of reported security issues, you have to have a strong explanation to "consume" all the "probability advantage" of the product with the fewer security issues.

>
> A

Do you need help?X

/Erik

Date: Fri, 27 Jul 2007 16:16:30 +0200
From: Florian Kulzer <florian.kulzer+debian@icfo.es> To: debian-user@lists.debian.org
Subject: Re: Sarge: Lost # of failed logins 

Message-ID: <20070727141630.GA13841@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Jul 27, 2007 at 08:50:46 -0500, Mumia W.. wrote:

[...]

> Hmm. My /var/log/faillog was missing, but even when I 'touch' it, the
> behavior doesn't change. My FAILLOG_ENAB is also "yes" in /etc/login.defs.

Do you get the normal output when you run "faillog"?

$ faillog 

Login       Failures Maximum Latest                   On
root            0        0   07/09/07 09:44:25 +0200  tty1
florian         0        0   07/27/07 09:15:42 +0200  tty1
Do you need more help?X

> In my /etc/pam.d/login file, "session optional pam_lastlog.so" is
> enabled.

I have the same entry. My impression is that this module is responsible for the "Last login: $DATE on $TERMINAL" output. The message "n failure(s) since last login" seems to triggered later, after pam_motd.so and pam_mail.so have done their job. 

-- 
Regards,            | 
http://users.icfo.es/Florian.Kulzer
          Florian   |

Date: Fri, 27 Jul 2007 16:43:28 +0200 From: Magnus Pedersen <bofhenator@gmail.com> To: debian-user@lists.debian.org Subject: libcbtsysinfo in /home/user Message-ID: <f8d0ag$hml$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have a new dir in /home/magnus, /home/magnus/cbt and I have not put it there. It contains cbt/lib/libcbtsysinfo_0.so and google draws a blank on that filename. Has my system been compromised (theres is nothing out of the ordinary anywhere else) or is there something I have missed? /Magnus

Date: Fri, 27 Jul 2007 16:45:48 +0200 From: =?ISO-8859-1?Q?J=F6rg-Volker_Peetz?= <peetz@scai.fraunhofer.de> To: debian-user@lists.debian.org Subject: Re: cannot logoff/shutdown properly Message-ID: <f8d0es$i8i$1@sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From time to time I have a similar problem on a Compaq notebook with ATI graphic card. In my case the display comes back after pushing the little pin shortly which is pressed down by the lid when closing the notebook. --=20 Regards, J=F6rg-Volker.

Date: Fri, 27 Jul 2007 09:42:42 -0500 From: John Hasler <jhasler@debian.org> To: debian-user@lists.debian.org Subject: Re: minimal firewall computer Message-ID: <873az9oql9.fsf@toncho.dhh.gt.org> Content-Type: text/plain; charset=us-ascii Ron Johnson writes:
> Most "home market" routers should also have built-in firewall and dhcp
> functionality.
A crappy firewall with no security support made by people with a reputation for shipping buggy software. -- John Hasler

Date: Fri, 27 Jul 2007 16:12:19 +0100 From: "Ari Constancio" <ari.constancio@gmail.com> To: "John Hasler" <jhasler@debian.org> Cc: debian-user@lists.debian.org Subject: Re: minimal firewall computer Message-ID: <66e82c800707270812q96d280as1e851bb2aad2eb31@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Wireless routers such as the venerable Linksys WRT54GL can use 3rd-party firmware like OpenWRT and voil=E1... instant Linux router (with iptables and such). Ari Constancio On 7/27/07, John Hasler <jhasler@debian.org> wrote:
> Ron Johnson writes:
> > Most "home market" routers should also have built-in firewall and dhcp
> > functionality.
>
> A crappy firewall with no security support made by people with a reputati=
on
> for shipping buggy software.
> --
> John Hasler
> >
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian=
.org > >

Date: Fri, 27 Jul 2007 08:25:16 -0700 From: Alan Ianson <agianson@gmail.com> To: debian-user@lists.debian.org Subject: Re: searching for graphical torrent client Message-Id: <200707270825.16096.agianson@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri July 27 2007 03:07, Giorgos D. Pallas wrote:
> I tried google but can't seem to find something that both looks decent
> *and* is available for debian (testing) as a binary. For example I tried
> qtorrent, but it is so minimal that I don't like it...
When I need a torrent app I have always used the good old bittorrent on the terminal. I guess it's not pretty (it's not bad though), but it works wonderfully.
> Or to put it in another way: Which client resembles most the windows
> utorrent? (I also tried ktorrent for KDE and it crashes often...)
Not sure what utorrent looks like but I have also used ktorrent on a few occasions and it also worked well, and it looks nice. It has never crashed here so I'm not sure what the problem could be.

Date: Fri, 27 Jul 2007 21:00:07 +0530 From: "Sridhar M.A." <mas@mylug.org> To: Debian Users <debian-user@lists.debian.org> Subject: Imagemagick Message-ID: <20070727153007.GA3175@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I do not know whether this has been answered or not (for I could not find anything in the archives) : Is there any reason that the newer version of imagemagick is not even in the unstables branch? Regards, -- Sridhar M.A. GPG KeyID : F6A35935 Fingerprint: D172 22C4 7CDC D9CD 62B5 55C1 2A69 D5D8 F6A3 5935 How can you think and hit at the same time? -- Yogi Berra

Can we help you?X

Date: Fri, 27 Jul 2007 10:39:57 -0500 From: Owen Heisler <owenh000@gmail.com> To: debian-user@lists.debian.org Subject: Re: searching for graphical torrent client Message-ID: <20070727153957.GA27926@owenh.hopto.org> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Fri, Jul 27, 2007 at 08:25:16AM -0700, Alan Ianson wrote:
> On Fri July 27 2007 03:07, Giorgos D. Pallas wrote:
> > I tried google but can't seem to find something that both looks decent
> > *and* is available for debian (testing) as a binary. For example I tried
> > qtorrent, but it is so minimal that I don't like it...
>
> When I need a torrent app I have always used the good old bittorrent on the
> terminal. I guess it's not pretty (it's not bad though), but it works
> wonderfully.
rtorrent works well, with a ncurses interface and session management. It's faster than all the rest in my experience.

Date: Fri, 27 Jul 2007 17:45:18 +0200 From: Florian Kulzer <florian.kulzer+debian@icfo.es> To: debian-user@lists.debian.org Subject: Re: Imagemagick Message-ID: <20070727154518.GA16050@localhost> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 27, 2007 at 21:00:07 +0530, Sridhar M.A. wrote:
> I do not know whether this has been answered or not (for I could not
> find anything in the archives) : Is there any reason that the newer
> version of imagemagick is not even in the unstables branch?
See bug #420672, followup 4. -- Regards, | http://users.icfo.es/Florian.Kulzer Florian |

Date: Fri, 27 Jul 2007 17:03:12 +0100 From: koffiejunkie <koffiejunkielistlurker@koffiejunkie.za.net> To: debian-user@lists.debian.org Subject: Re: minimal firewall computer Message-ID: <46AA1740.9070000@koffiejunkie.za.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ari Constancio wrote:
> Hi,
>=20
> Wireless routers such as the venerable Linksys WRT54GL can use
> 3rd-party firmware like OpenWRT and voil=E1... instant Linux router
> (with iptables and such).
Some, like the Netgear DG834, is already running Linux with iptables.

Date: Fri, 27 Jul 2007 12:03:10 -0400 From: Celejar <celejar@gmail.com> To: debian-user <debian-user@lists.debian.org> Subject: ndiswrapper build failure Message-Id: <20070727120310.539387cc.celejar@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'm trying to build ndiswrapper against a self compiled 2.6.22 kernel. It fails as follows:
> .../modules/ndiswrapper/ndis.c:2825:47: error: macro "INIT_WORK" passed=
3 arguments, but takes just 2
> .../modules/ndiswrapper/ndis.c: In function =E2=80=98ndis_init=E2=80=99=
:
> .../modules/ndiswrapper/ndis.c:2825: error: =E2=80=98INIT_WORK=E2=80=99=
undeclared (first use in this function)
> .../modules/ndiswrapper/ndis.c:2825: error: (Each undeclared identifier=
is reported only once
> .../modules/ndiswrapper/ndis.c:2825: error: for each function it appear=
s in.) I've googled, but not found anything really helpful. Apparently the kernel code changed recently, from requiring 3 to 2 arguments for INIT_WORK, but I have had no trouble through 2.6.21. Is this a bug? Do I need to change something in my kernel config? Anyone else seeing this? Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator End of debian-user-digest Digest V2007 Issue #2040 ************************************************** Received on Fri Jul 27 12:31:23 2007

This archive was generated by hypermail 2.1.8 : Thu Aug 09 2007 - 19:05:32 EDT

Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library