Re: FreeBSD and User Security
On Wed, 11 Jun 2008 22:25:32 +0200 David Naylor <[EMAIL PROTECTED]> wrote: > Hi All, > > Today I read an article describing how my government had lost > ZAR200 000 000 from fraud. This is just under $25 000 000. The > article credited this loss largely due to the use of spyware. > > My question is how secure is FreeBSD (including KDE, GNOME and > XFCE) to attacks, including cracking and spyware. In addition, is > there anyway to prevent a user from executing a program that is not > owned by root (i.e. any program installed by the user), this would > prevent spyware being installed (assuming root has been properly > locked down) and subsequently run. Ugidfw(8) can be used to help with the executable stuff. The same is true for using a restricted shell. The important thing is making sure to make sure the user can't execute any thing other than the few commands they are suppose to. If allowed access to execute any thing in a system bin/sbin path, you begin to run into issues with interpreters, which are as good as being able to execute something owned by them. You can remove permissions to access them, but that strikes me as beginning to get a bit hairy in the long run. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Jun 12, 2008, at 3:24 PM, David Naylor wrote: This is a general enquiry. What had sparked my interest in this subject is the above mentioned article. In this case it is a workstation used to access and manage account and cash flows. The threat would be anyone gaining access to 'divert' funds to incorrect accounts, for obvious personal gains. How much money are we talking about? If it is billions of NZD that is one thing, if it is thousands of NZD that is another. The question is would someone with resources make a concerted effort to specifically target your system? If so, you should hire a local professional. If your concern is more about the kinds of wide spread automated attacks, then really it's just a matter of doing the basic sorts of things. Disabling root SSH logins, have your perimeter firewall check for unusual out-bound traffic, and of course, keeping the system properly updated. Specifically, the two threats would be remote attach (such as spyware being deployed, or gaining remote access) I haven't played around with it, but you might want to look at Mandatory Access Control (described in the Handbook). It's something that has been on my "to learn" list for a while, but I am getting through that list very slowly. From what you've said, it sounds like you are talking about a multi-user system. Something like MAC really may be the best approach to preventing individual users from being tricked into doing stupid things. or physical access (in which case keeping the username and password safe will be the only option? Assuming their is no compromise on the human side) For a typical machine, physical access means all access. If I have physical access to a machine, I may be able to boot it from my own boot media (a CD for example) and then read everything on the hard disks. I could remove the disks and copy them. I could install a physical keystroke logger between the keyboard and the box. There really is a lot that can be done with physical access. So if you have reason to believe that attackers would have physical access to the machine, you should use encrypted file systems. Note that with both MAC and encrypted file systems you run an increased risk of locking yourself out of the system by accident. So what measures you wish to take, with their additional costs and risks, depends on a careful and realistic view of what the threats are. I've enjoyed this discussion. Cheers, -j ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Thursday 12 June 2008 18:43:40 you wrote: > On Jun 12, 2008, at 8:19 AM, David Naylor wrote: > > I think this argument is rather mute, just because there are no > > programs > > exploiting security vulnerabilities does not been there are not > > vulnerabilities, > > But it is far from moot if you are interested in the actual threat > against your system. In a sense, using a less popular OS is a form of > "security by obscurity" which is not to be heavily relied on, but > still it does make a real, practical, difference in the case that you > described. Very true, however having a large scale usage of FreeBSD (for example, if a government were to adopt it) would bring pressure to bare. For anything but such a large scale adoption in the medium to long term then it is a valuable 'asset'. > > and a determined cracker would create his own program. > > You have not articulated what you are trying to defend against. Do > you anticipate determined crackers going after your particular system > and what resources will such attackers have? We can't talk about a > system being "secure" in general, but the question needs to be framed > in terms of "secure against what". This is a general enquiry. What had sparked my interest in this subject is the above mentioned article. In this case it is a workstation used to access and manage account and cash flows. The threat would be anyone gaining access to 'divert' funds to incorrect accounts, for obvious personal gains. Specifically, the two threats would be remote attach (such as spyware being deployed, or gaining remote access) or physical access (in which case keeping the username and password safe will be the only option? Assuming their is no compromise on the human side) > > That said I hope there are, actually, no vulnerabilities. > > That is demanding too much. What you need to hope for is a > combination of "no known unpatched vulnerabilities at the moment" and > more importantly "procedures and practices to keep things that way". > As Bruce Schneier likes to say, "Security is not a product but a > process". The vast majority of actual system compromises involve > failure of system administrators to keep systems patched and follow > good security practices. Good point! Thank goodness for automatic signed incremental updates (that actually work) Leason: always keep your system up-to-date! (With security patches) > One reason that I switched from Linux to FreeBSD is that I find it > much easier to maintain FreeBSD, particularly in terms of security > updates. I have been responsible for Linux machines that did get > rooted because I was having problems keeping them up-to-date for a > variety of reasons. > > > [Security through obscurity is just an illusion] > > In your post you mentioned concern about spyware. It is not an > illusion that FreeBSD has not been targeted by spyware writers while > Windows has. Even if some of that is the consequence of security by > obscurity, it is no illusion. Of course we need to understand that > those security benefits from obscurity are fragile, but we shouldn't > dismiss it entirely. Point taken. > Again, what sorts of benefits such things may add (or subtract) > depends on the nature of the attacker. Thank you for your feedback David signature.asc Description: This is a digitally signed message part.
Re: FreeBSD and User Security
But it is far from moot if you are interested in the actual threat against your system. In a sense, using a less popular OS is a form of "security by obscurity" which is not to be heavily relied on, but still it does make a real, practical, difference in the case that you described. FreeBSD is "unfortunately" quite popular OS, but yes - much less popular than linux, not to mention windoze. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Jun 12, 2008, at 8:19 AM, David Naylor wrote: I think this argument is rather mute, just because there are no programs exploiting security vulnerabilities does not been there are not vulnerabilities, But it is far from moot if you are interested in the actual threat against your system. In a sense, using a less popular OS is a form of "security by obscurity" which is not to be heavily relied on, but still it does make a real, practical, difference in the case that you described. and a determined cracker would create his own program. You have not articulated what you are trying to defend against. Do you anticipate determined crackers going after your particular system and what resources will such attackers have? We can't talk about a system being "secure" in general, but the question needs to be framed in terms of "secure against what". That said I hope there are, actually, no vulnerabilities. That is demanding too much. What you need to hope for is a combination of "no known unpatched vulnerabilities at the moment" and more importantly "procedures and practices to keep things that way". As Bruce Schneier likes to say, "Security is not a product but a process". The vast majority of actual system compromises involve failure of system administrators to keep systems patched and follow good security practices. One reason that I switched from Linux to FreeBSD is that I find it much easier to maintain FreeBSD, particularly in terms of security updates. I have been responsible for Linux machines that did get rooted because I was having problems keeping them up-to-date for a variety of reasons. [Security through obscurity is just an illusion] In your post you mentioned concern about spyware. It is not an illusion that FreeBSD has not been targeted by spyware writers while Windows has. Even if some of that is the consequence of security by obscurity, it is no illusion. Of course we need to understand that those security benefits from obscurity are fragile, but we shouldn't dismiss it entirely. Again, what sorts of benefits such things may add (or subtract) depends on the nature of the attacker. Cheers, -j ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, Jun 11, 2008 at 10:25:32PM +0200, David Naylor wrote: > > Hi All, > > Today I read an article describing how my government had lost ZAR200 000 000 > from fraud. This is just under $25 000 000. The article credited this loss > largely due to the use of spyware. > > My question is how secure is FreeBSD (including KDE, GNOME and XFCE) to > attacks, including cracking and spyware. In addition, is there anyway to > prevent a user from executing a program that is not owned by root (i.e. any > program installed by the user), this would prevent spyware being installed > (assuming root has been properly locked down) and subsequently run. > > If anyone, in addition, has answers for Linux and *BSD it would be great to > know as well. You might want to have a look at using a restricted shell for users. I know bash & pdksh have a restricted mode. A quick look at the manpages for sh & csh suggests they don't. Bash and pdksh are in ports. Can't tell you which is best as I haven't used either in restricted mode. > > Best Regards > > David Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wednesday 11 June 2008 23:47:43 you wrote: > On Wed, Jun 11, 2008 at 10:25:32PM +0200, David Naylor wrote: > > Hi All, > > > > Today I read an article describing how my government had lost ZAR200 000 > > 000 from fraud. This is just under $25 000 000. The article credited > > this loss largely due to the use of spyware. > > > > My question is how secure is FreeBSD (including KDE, GNOME and XFCE) to > > attacks, including cracking and spyware. > > That is a very broad question without a simple answer. It depends among > other things on the purpose of the machine and the knowledge of the > administrator. > > E.g, if you are creating a workstation that doesn't run externally > accessible servers you could configure the firewall to block all > incoming new connection requests. That will go a long way toward > safeguarding the machine against network attacks. > > There is no way to safeguard a machine that an attacker has physical > access to; he could e.g. steal the harddisk and read your data at his > leisure (unless it is encrypted on-disk, e.g. with geli(8)). Also, no OS > can defend against social engineering attacks. > > I would not worry overly much about spyware. Most if not all of those > are windows binaries. Also, unix mail clients as a rule do not execute > scripts embedded in mail messages. I think this argument is rather mute, just because there are no programs exploiting security vulnerabilities does not been there are not vulnerabilities, and a determined cracker would create his own program. That said I hope there are, actually, no vulnerabilities. [Security through obscurity is just an illusion] > > In addition, is there anyway to > > prevent a user from executing a program that is not owned by root (i.e. > > any program installed by the user), this would prevent spyware being > > installed (assuming root has been properly locked down) and subsequently > > run. > > You could mount /home and other partitions where users have write access > like /tmp with the noexec option. Note that that wouldn't block the > execution of scripts, just binaries. Excellent idea, that would work just fine :-). I think /var/tmp should be added to the list. If a script is run using #!/bin/sh would that then be executable with noexec (i.e. running "./example.sh" instead of "sh ./example.sh) Thank you to everyone who has replied, it was been informative. Regards David signature.asc Description: This is a digitally signed message part.
Re: FreeBSD and User Security
of "interesting non-essentials"? It's been a few years since bios were delivered in socketed ROMs/EPROMs (readable by a standalone device, independently of their own operation) or since sources were typically published :) now they are standard devices too, just not socketed, you may unsolder and check ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Thu, Jun 12, 2008 at 01:03:00AM -0700, [EMAIL PROTECTED] wrote: > > How do you know that the bios has not been reflashed by a virus, > > trojan, or rootkit? > > For that matter, how do you know that the *original* bios was free > of "interesting non-essentials"? It's been a few years since bios > were delivered in socketed ROMs/EPROMs (readable by a standalone > device, independently of their own operation) or since sources were > typically published :) Check out http://www.gensw.com and the book _BIOS Disassembly Ninjutsu Uncovered_. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
> > It is my understanding that since 1995 all computers must have > > a hardware back door that permits undetectable access by the > > government to the computer. This capability can be implemented > > using System Monitor(Maintenance) Mode which is built into all > > x86 computers now. It would appear that, if you are connected > > to the internet, the government has access to your computer. > > if it were true, this "system maintenance mode" would have to > access your network card in parallel with main OS without making > conflicts A near-trivial exercise in virtualization, provided it knows what kind of card is in use and what addresses it occupies, which is rather easy if the "card" is in fact built onto the mainboard. Of course, it is also trivial to defeat it by using an add-in card instead of the one on the mainboard, esp. a card whose design did not exist when the bios was written. Cycles consumed by SMM might also explain why some PCs' clocks seem to run slower than real time ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
> How do you know that the bios has not been reflashed by a virus, > trojan, or rootkit? For that matter, how do you know that the *original* bios was free of "interesting non-essentials"? It's been a few years since bios were delivered in socketed ROMs/EPROMs (readable by a standalone device, independently of their own operation) or since sources were typically published :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
David It is my understanding that since 1995 all computers must have a hardware back door that permits undetectable access by the government to the computer. This capability can be implemented using System Monitor(Maintenance) Mode which is built into all x86 computers now. It would appear that, if you are connected to the internet, the government has access to your computer. if it were true, this "system maintenance mode" would have to access your network card in parallel with main OS without making conflicts ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Jun 11, 2008, at 9:05 PM, [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 08:51:16PM -0500, Jeffrey Goldberg wrote: The next time I reboot the one server I've got with an SVM capable processor I'm going to disconnect the power (to make sure that I'm getting a real reboot instead of a spoofed one) and then on reboot I will disable SVM in the BIOS. How do you know that the bios has not been reflashed by a virus, trojan, or rootkit? Aghh!! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, Jun 11, 2008 at 08:51:16PM -0500, Jeffrey Goldberg wrote: > On Jun 11, 2008, at 8:08 PM, cpghost wrote: > >> On Wed, 11 Jun 2008 19:45:51 -0500 >> Jeffrey Goldberg <[EMAIL PROTECTED]> wrote: > >>> First it should consume memory. A very complete test of memory >>> through a modified memtest should be able to detect whether system >>> reported memory is accurate. > >> What if memtest already runs within the virtualization box? How can it >> determine what the "right" amount of memory is supposed to be? > > I was assuming that that would be known by the operator. > >> And if >> the virtualizer hot-patched memtest instructions, either on loading it >> or dynamically while it runs, it could make it report whatever it >> liked. > > Of course. > >>> Secondly, a blue pill would need to be reinserted after a hard >>> reboot. Therefore a look at the boot process (of a non-live system) >>> should be able to see whether there is something that reinserts the >>> blue pill. > >> Yes, but you've got to have a very close look at it, as it won't >> necessarily appear on the screen -- being caught as well by the >> virtualizer. And Joanna also has a paper about fooling hardware >> capture cards into reporting bogus data on her site, so you won't >> even be able to detect that RAM contains something else upon boot >> than those hardware capture cards are supposedly reporting. > > Yes. I've now read through some of Rutowska's slides (following the link > provided by dfeustel in another post in this thread). > >> If all this is as she's described, it is truly brilliant from a >> technical POV... and a very worrying thought as well. > > Yes it is worrying. The next time I reboot the one server I've got with an > SVM capable processor I'm going to disconnect the power (to make sure that > I'm getting a real reboot instead of a spoofed one) and then on reboot I > will disable SVM in the BIOS. How do you know that the bios has not been reflashed by a virus, trojan, or rootkit? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Jun 11, 2008, at 8:08 PM, cpghost wrote: On Wed, 11 Jun 2008 19:45:51 -0500 Jeffrey Goldberg <[EMAIL PROTECTED]> wrote: First it should consume memory. A very complete test of memory through a modified memtest should be able to detect whether system reported memory is accurate. What if memtest already runs within the virtualization box? How can it determine what the "right" amount of memory is supposed to be? I was assuming that that would be known by the operator. And if the virtualizer hot-patched memtest instructions, either on loading it or dynamically while it runs, it could make it report whatever it liked. Of course. Secondly, a blue pill would need to be reinserted after a hard reboot. Therefore a look at the boot process (of a non-live system) should be able to see whether there is something that reinserts the blue pill. Yes, but you've got to have a very close look at it, as it won't necessarily appear on the screen -- being caught as well by the virtualizer. And Joanna also has a paper about fooling hardware capture cards into reporting bogus data on her site, so you won't even be able to detect that RAM contains something else upon boot than those hardware capture cards are supposedly reporting. Yes. I've now read through some of Rutowska's slides (following the link provided by dfeustel in another post in this thread). If all this is as she's described, it is truly brilliant from a technical POV... and a very worrying thought as well. Yes it is worrying. The next time I reboot the one server I've got with an SVM capable processor I'm going to disconnect the power (to make sure that I'm getting a real reboot instead of a spoofed one) and then on reboot I will disable SVM in the BIOS. But mostly I'm just in admiration of people who can think of things this clever (even if they are very scary and dangerous things). Thank y'all for a very enlightening discussion. -j ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, 11 Jun 2008 19:45:51 -0500 Jeffrey Goldberg <[EMAIL PROTECTED]> wrote: > On Jun 11, 2008, at 7:17 PM, [EMAIL PROTECTED] wrote: > > > A relatively new security threat known as 'The Blue Pill', based > > upon hardware, is a class of virtual rootkits that can silently > > take over Intel and AMD systems. A good site to visit to learn > > about these virtual > > rootkits is http://invisiblethings.org/index.html. > > That is simple (in concept) yet absolutely brilliant! I'm sure that > people much smarter that I am have thought about these things more > carefully than I have, but I'm not convinced that a blue pill would > be completely undetectable. > > First it should consume memory. A very complete test of memory > through a modified memtest should be able to detect whether system > reported memory is accurate. What if memtest already runs within the virtualization box? How can it determine what the "right" amount of memory is supposed to be? And if the virtualizer hot-patched memtest instructions, either on loading it or dynamically while it runs, it could make it report whatever it liked. > Secondly, a blue pill would need to be reinserted after a hard > reboot. Therefore a look at the boot process (of a non-live system) > should be able to see whether there is something that reinserts the > blue pill. Yes, but you've got to have a very close look at it, as it won't necessarily appear on the screen -- being caught as well by the virtualizer. And Joanna also has a paper about fooling hardware capture cards into reporting bogus data on her site, so you won't even be able to detect that RAM contains something else upon boot than those hardware capture cards are supposedly reporting. If all this is as she's described, it is truly brilliant from a technical POV... and a very worrying thought as well. > But even if detection is possible these ways, a Blue Pill would be > extremely difficult to detect once inserted, and so the focus would > have to be entirely on prevention. > > Again, these are just my first thoughts after looking at this very > briefly. The people who come up with this stuff and do proper > analysis are both smarter and more knowledgeable than I am. > > Cheers, > > -j -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, Jun 11, 2008 at 07:45:51PM -0500, Jeffrey Goldberg wrote: > On Jun 11, 2008, at 7:17 PM, [EMAIL PROTECTED] wrote: > >> A relatively new security threat known as 'The Blue Pill', based upon >> hardware, is a class of virtual rootkits that can silently take over >> Intel and AMD systems. A good site to visit to learn about these virtual >> rootkits is http://invisiblethings.org/index.html. > > That is simple (in concept) yet absolutely brilliant! I'm sure that people > much smarter that I am have thought about these things more carefully than > I have, but I'm not convinced that a blue pill would be completely > undetectable. Check out also http://bluepillproject.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Jun 11, 2008, at 7:17 PM, [EMAIL PROTECTED] wrote: A relatively new security threat known as 'The Blue Pill', based upon hardware, is a class of virtual rootkits that can silently take over Intel and AMD systems. A good site to visit to learn about these virtual rootkits is http://invisiblethings.org/index.html. That is simple (in concept) yet absolutely brilliant! I'm sure that people much smarter that I am have thought about these things more carefully than I have, but I'm not convinced that a blue pill would be completely undetectable. First it should consume memory. A very complete test of memory through a modified memtest should be able to detect whether system reported memory is accurate. Secondly, a blue pill would need to be reinserted after a hard reboot. Therefore a look at the boot process (of a non-live system) should be able to see whether there is something that reinserts the blue pill. But even if detection is possible these ways, a Blue Pill would be extremely difficult to detect once inserted, and so the focus would have to be entirely on prevention. Again, these are just my first thoughts after looking at this very briefly. The people who come up with this stuff and do proper analysis are both smarter and more knowledgeable than I am. Cheers, -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, Jun 11, 2008 at 06:53:18PM -0500, Jeffrey Goldberg wrote: > [mailed and posted] > > On Jun 11, 2008, at 4:03 PM, YANSWBVCG wrote: > >> It is my understanding that since 1995 all computers must have a >> hardware back door that permits undetectable access by the government to >> the computer. This capability can be implemented using System >> Monitor(Maintenance) Mode which is built into all x86 computers now. It >> would appear that, if you are connected to the internet, the government >> has access to your computer. > > This is not the place to get into this debate, but I think that someone > should state for the record that the vast majority of security experts > would disagree with you. A relatively new security threat known as 'The Blue Pill', based upon hardware, is a class of virtual rootkits that can silently take over Intel and AMD systems. A good site to visit to learn about these virtual rootkits is http://invisiblethings.org/index.html. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
[mailed and posted] On Jun 11, 2008, at 4:03 PM, YANSWBVCG wrote: It is my understanding that since 1995 all computers must have a hardware back door that permits undetectable access by the government to the computer. This capability can be implemented using System Monitor(Maintenance) Mode which is built into all x86 computers now. It would appear that, if you are connected to the internet, the government has access to your computer. This is not the place to get into this debate, but I think that someone should state for the record that the vast majority of security experts would disagree with you. However, I fully acknowledge that if the National Security Agency or GCHQ or the like wanted to break into any one of my systems, I'm sure that they could. But the question wasn't about making a system that could withstand something like the NSA but instead about defending against run of the mill spyware. Switching from Windows to FreeBSD would obviously improve matters for that kind of attack, but the real answers to the original question require an understanding of the nature of the threats and the nature of the counter measures far beyond what was evident in the question. After all, most spyware is installed with the users' consent (though the user may not know that it is sypware.) For just about everyone, I recommend pretty much anything written by Bruce Schneier. As as start there is his very brief "How to think about security" essay: http://www.schneier.com/crypto-gram-0204.html#1 -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, Jun 11, 2008 at 10:25:32PM +0200, David Naylor wrote: > Hi All, > > Today I read an article describing how my government had lost ZAR200 000 000 > from fraud. This is just under $25 000 000. The article credited this loss > largely due to the use of spyware. > > My question is how secure is FreeBSD (including KDE, GNOME and XFCE) to > attacks, including cracking and spyware. In addition, is there anyway to > prevent a user from executing a program that is not owned by root (i.e. any > program installed by the user), this would prevent spyware being installed > (assuming root has been properly locked down) and subsequently run. > > If anyone, in addition, has answers for Linux and *BSD it would be great to > know as well. > > Best Regards > > David It is my understanding that since 1995 all computers must have a hardware back door that permits undetectable access by the government to the computer. This capability can be implemented using System Monitor(Maintenance) Mode which is built into all x86 computers now. It would appear that, if you are connected to the internet, the government has access to your computer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and User Security
On Wed, Jun 11, 2008 at 10:25:32PM +0200, David Naylor wrote: > Hi All, > > Today I read an article describing how my government had lost ZAR200 000 000 > from fraud. This is just under $25 000 000. The article credited this loss > largely due to the use of spyware. > > My question is how secure is FreeBSD (including KDE, GNOME and XFCE) to > attacks, including cracking and spyware. That is a very broad question without a simple answer. It depends among other things on the purpose of the machine and the knowledge of the administrator. E.g, if you are creating a workstation that doesn't run externally accessible servers you could configure the firewall to block all incoming new connection requests. That will go a long way toward safeguarding the machine against network attacks. There is no way to safeguard a machine that an attacker has physical access to; he could e.g. steal the harddisk and read your data at his leisure (unless it is encrypted on-disk, e.g. with geli(8)). Also, no OS can defend against social engineering attacks. I would not worry overly much about spyware. Most if not all of those are windows binaries. Also, unix mail clients as a rule do not execute scripts embedded in mail messages. > In addition, is there anyway to > prevent a user from executing a program that is not owned by root (i.e. any > program installed by the user), this would prevent spyware being installed > (assuming root has been properly locked down) and subsequently run. You could mount /home and other partitions where users have write access like /tmp with the noexec option. Note that that wouldn't block the execution of scripts, just binaries. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpvn8FSPGygZ.pgp Description: PGP signature
Re: FreeBSD and User Security
from fraud. This is just under $25 000 000. The article credited this loss largely due to the use of spyware. My question is how secure is FreeBSD (including KDE, GNOME and XFCE) to do not include that programs to FreeBSD. they are not it's part. it's just few of thousand programs that can run under FreeBSD. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD and User Security
Hi All, Today I read an article describing how my government had lost ZAR200 000 000 from fraud. This is just under $25 000 000. The article credited this loss largely due to the use of spyware. My question is how secure is FreeBSD (including KDE, GNOME and XFCE) to attacks, including cracking and spyware. In addition, is there anyway to prevent a user from executing a program that is not owned by root (i.e. any program installed by the user), this would prevent spyware being installed (assuming root has been properly locked down) and subsequently run. If anyone, in addition, has answers for Linux and *BSD it would be great to know as well. Best Regards David signature.asc Description: This is a digitally signed message part.