The goal: to be able to differentiate packages that cause systemwide changes from "harmless programs"
Why: To increase security when an unexperienced user decides to try new packages

Users very often get package recommendations from places which are not 100% worthy of trust, like internet foruns. A malicious (or poorly informed) suggestion can cause a users computer to became an open relay to send spam, or an ssh server for a hacker to bruteforce his way in.

To avoid that, it would be nice to have a "safe packages" list, of programs that

* dont use suid
* dont open network ports
* dont change the boot sequence
* dont affect any user of the computer that does not call the program in any way

in other words: can be installed without creating any security concerns

I think there is a possibility for making all the folder names in an operating system generic
(and thus enhancing security) by making a central folder registry that updates on
changes in the folder structure. Even this central registry can be placed arbitrarily
by deploying it as a registry with an agent that reports itself to the proper place in
the operating system.

I mean, a person new to the Operating System would not have a chance
going into this unknown "sea" of folders over the internet (from where, you know,
everything begins with unknowing starter).

Good?

There are a few bugs with the lock screen system. At present, they have been fixed. However, there is a fundamental problem - because the lock screen dialog runs on top of the user, any security flaw (or crash, or glitch, or anything which would close it or move it) can cause the desktop to be unlocked.

Using full-disk encryption adds another authentication step to the boot process, by default a passphrase. For most home users, this is probably an unnecessary complication and obstacle to the good security practice of encrypting their data. In addition, this doesn't fit well with a multi-user environment, as by default everyone has to share the encryption password. Full-disk encryption would be much more usable if the boot-up process was streamlined.

Many organisations, even if they are shifting over to an Ubuntu environment, will have many Windows PCs that need to be supported. Presently if you want to run a Windows Server Update Service (WSUS) you need to have a Windows Server (Microsoft). I believe being able to cache, test and deploy Windows Updates locally from the Ubuntu Update Server (Ubuntu Brainstorm) would be attractive to admins.

By default, a sudo timestamp is valid for 15 minutes, so any process running as your user within 15 minutes after you use sudo can easily gain root privileges, killing shells and creating new shells if necessary to use the same TTY as the sudo timestamp.

It doesn't matter how soon the timestamp is killed. If timestamps can be used at all, they can be used by a malicious process immediately after sudo is run.

Users should be warned when they connect to a network which is obviously insecure (such as connected to a Hub instead of Switch).

Its quite easy to program. If SYN|ACK or ACK packets are received which are directed to another MAC address, we know its insecure.

There are algorithms too which can even help detect Man-in-the-middle attacks (to identify when its very likely someone is trying to intercept/change your traffic),however, this is more difficult to program.

We should be trying to provide the highest level of security possible to users.

Since a lot of people seem to think that not showing visual feedback for password authentication (in the terminal, for example) is a security feature, let's remove visual feedback from the GUI, too.

See Idea #11118: Display *** for password in the terminal for more details:
http://brainstorm.ubuntu.com/idea/11118/

Hey Ubuntu Brainstormers,

I checked that, and it hasn't been proposed yet... As it is not a bug, it is an (unfortunate) feature, let's talk about it here and not in Launchpad.

You know that if you choose the "recovery mode" line in the Grub menu, you are able to have a full root access to your computer choosing "root" in the recovery menu (command line at first but just enter startx and hello Gnome) WITHOUT TYPING ANY PASSWORD.

That is a real problem. I mean, if I've got people at home and I go to pee, my guests have full time to easily get my naked girlfriend's pics and launch a rm -rf /* on my computer. That would be nasty.

I know, I know, anyway, you can do the same thing with a physical access to the computer and a LiveCD or a LiveUSB. But most of the people do not have those kind of items on them, while a lot of people could learn the easy "root" trick if Ubuntu was going mainstream (and if you care you can put a password on your BIOS for blocking alternate boot medias).

And this "feature" is not needed. If someone uses this root access to correct a problem on his computer, he should remember his admin password. And if he does not, he can use a liveCD to mingle. And this is kind of inconsistent with the Ubuntu choice to not have a root account by default.

Another unfortunate feature for the privacy on Ubuntu is the default read access to your documents by other users, but let's talk about that on another idea.

(Wasn't able to find "grub-pc" or "recovery mode" in the "related projects" category)

Short idea description:
It would be good to have an *official* list of end-of-life dates for each Ubuntu release.

Long idea description:
I have noticed that the release information and "end of life" dates (aka EoL) are listed at https://wiki.ubuntu.com/Releases

Instead of having to browse through news announcements at mailing lists or posts at the news, www.ubuntu.com should have a page that lists various important release info such as the end of life dates. A wiki page is not the official way to list important information such as this one.

Example: http://www.freebsd.org/security/#sup
They list end-of-life dates as a security-related part of information.

www.ubuntu.com could have a www.ubuntu.com/security page that lists the EoL of each release, and probably be merged with the list of www.ubuntu.com/usn somehow.

This list could be taken from the wiki.ubuntu.com and listing it at an www.ubuntu.com subpage would make people feel more ensured about the information provided there, since not everyone has access to edit information at that site.