Many of the time, I hear complains from my friends that they are getting infected after receiving files from Linux Users. The problem is that, 99.99% of the malwares are targetted towards Windows, thanks to its ill configuration and user-base. So, it is very possible that any malware gets introduced into a Linux Box, and resides there. We won't be able to detect it, and won't find it necessary too, since Ubuntu is nearly unbeatable by Viruses. But when sharing files with Windows users, the virus infects their System, giving rise to an ill conception that Ubuntu is infected.

I would appreciate it if both the brainstorm and ubuntuforums.org would be protected via SSL for login and cookie exchanges.

Virtually all other sites related to the wiki, documentation, launchpad, etc, use SSL, and I wish the same could be said about these as well.

In a recent forum discussion, some felt that there's no point to protecting those sites. But most will agree that many people use the same password for everything, and even though a compromise of a forum password may not seem like much, it could be an issue elsewhere.

Case in point, all wiki modifications show the IP address of those that make the changes. If this person uses the same password for the wiki as their forum account, not only is it a risk to the wiki, but if their personal machine is remotely accessible via SSH, etc, then that user is also at risk if the password is also the same on their computer.

Yes... people need to follow best practices... but if you have the ability to help people and it comes at virtually no cost to you, then why not?

Hope others feel the same way. Thanks for listening.

Ubuntu updates are currently delivered via standard HTTP calls to the repos. This is problematic for a number of reasons, including the following:

1. Possession of certain software (e.g., strong crypto [GnuPG], unapproved chat protocols, Tor) is illegal under certain repressive regimes. Plain HTTP fetching of these packages exposes users living without basic human rights to legal liability for possession of certain software. Any police state monitoring its subjects' Internet usage can identify and arrest those using these packages with trivial ease. This is the most practical of the problems with HTTP updates.

2. The update process lacks end-to-end integrity. While it is true that packages are signed, adding SSL to the update process adds another layer of security and integrity to the process by ensuring that the update stream cannot be intercepted or tampered with. This could, hypothetically, avert an attack should a future vulnerability be discovered in signing verification logic, or should a crucial signing key be compromised. End-to-end SSL, with verification of Canonical's certificate by the update manager, ensures that all update packages must pass through official servers. This problem is currently more hypothetical than practical.

3. The update process exposes the identity of software running on client systems. End-to-end SSL increases the difficulty of identifying which packages are actively in use, and deprives an attacker with read access to network traffic of important intelligence which might be useful in future attacks (such as in the case of an attacker who compromises an enterprise router). While it is true that active packages can be guessed at by watching the times and sizes of downloaded updates, this adds additional difficulty to an attacker's efforts. This problem is quite hypothetical.

Actually, the program vinagre don't implements SSH security.

If we put a password to connect to a remote desktop, an black hacker can intercepts the password.

I am using Luks encryption for /home, /swap and /root partition on my Ubuntu 7.10 system but these day some research papers and USB boot application have show it is easy to get encryption key in ram by reboot linux system.

papers and the operation process are in following links
[quote]
Creating bootable USB drives for capturing the contents of memory
http://mcgrewsecurity.com/projects/msramdmp/

Cold Boot Attacks on Encryption Keys
http://citp.princeton.edu/memory/
[/quote]

So Ubuntu need to introduce some way to gradually clean info remained in RAM during system shutdown process to prevent this encryption key disclosure through cold reboot.

Consider the possibility of replay attacks as described in the following link:

http://www.cs.arizona.edu/people/justin/packagemanagersecurity/

It ought to be possible to add extra security to the package manager.

On any folder/directory,
right click,
encrypt directly...

and ability to decrypt it with pass...easily..

Lets face it, no matter how much the linux security model makes since it has undiscovered Holes. Ubuntu is going to market with the idea of being less likely to be infected than windows. However by reading across the internet security holes are being tested as exploits at an alarming rate since 2009. My idea is to implement a more preemptive program for discovering these issues and fixing them. (Think offensive security!)I know as of now most linux users are keen to intelligent practices in how we install, however more and more non technical users are moving to linux partially for peace of mind. They will want to install software outside of included repos. Even google has been proven hackable!

Software should be written to maximize the chances of finding a stolen laptop (or desktop), and installed with Ubuntu by default.

Many small-time opportunistic thieves (common at colleges) don't know much about computers, especially Linux, and can be tracked and caught when logging into the Guest account. There are many stories of people being caught after stealing cell phones and posting pictures online, etc.

The simplest thing it can do is to log its external IP addresses (checkip.dyndns.org) so they can be given to the police. But there are many other things it can do:

- Log all nearby wireless access nodes SSIDs and MAC address
- GPS coordinates
- Traceroute information
- Take screenshots
- Take pictures with built-in webcam
- Record from built-in microphones?

These can either be sent to a server (Ubuntu could provide one, but you could configure your own as well) or the data could be emailed to you so it doesn't need any other servers.

Many proprietary programs already exist that do some of these things. I can only find one, Adeona, for Linux, though Ubuntu refuses to package it.

Here's an Ubuntu DynDNS tracker.

Here is a "phone home" Perl script for OS X.

Other software:

[....]

It is quite easy to trick the user into running a bad script in sudo by changing the gnome menu from "gksu /usr/sbin/synaptic" to "gksu /home/user/.roughescript.sh".

In a desktop environment using sudo you should need to enter your password in order to change the menu.

Sorry if i misspelt something; English is not my native language.