Right now, any application a user runs can access the network and send whatever it pleases anywhere it likes.

Ubuntu users shouldn't have to wonder if any of the programs on their system are 'phoning home' to check for updates - or worse, to upload information about them in a sneaky way.

I propose that we package strict network access profiles along with every application that needs to use the network.
If no network access profile is present in an application's .deb file, Ubuntu should NOT allow it to access the network.

It should be up to the package maintainer to find out if an application needs to open any 'listening' ports, or access an outside server, etc. The maintainer should then write and include the strictest workable profile possible.

Both SELinux and AppArmor might be able to handle implementation of this kind of policy already. We're already including AppArmor and SeLinux profiles for some applications; we just need the default policies to be stricter. In addition, we may want to configure the iptables firewall as well.

Something like the Authorizations control panel would be great in terms of a UI for seeing which application is permitted to do what. Perhaps PolicyKit integration could allow us to grant or revoke application network access privileges.

Binary drivers on top of a stable application binary interface makes it feasible for hardware manufacturers to release device drivers without source code. Also drivers can be run with restricted rights.

Currently, if an app can use gnome-keyring to store a password, there is no way the app can ask gnome-keyring if the key is currently on the keyring, without unlocking it (and exposing all the passwords).

The upshot of this is: Any app which can use gnome-keyring is constantly pestering the user to unlock the keyring, even if the key isn't stored there. If the user gives in to this badgering and unlocks his or her keyring ("See, stupid app, there's no password for you in my keyring!!"), then all the passwords that ARE in the keyring become insecure. And the app still needs to prompt for the password anyway!

Fedora has an excellent initiative to consolidate core applications on Mozilla's NSS[1] crypto library.[2]

This would significantly ease security management for system administrators and hopefully improve SSO systems for end users.

It would be great to see the distros work together to make this happen as its really not something we can expect to be solved upstream.

[1] http://developer.mozilla.org/en/NSS
[2] http://fedoraproject.org/wiki/FedoraCryptoConsolidation

DNSSEC is going to be the next "big thing" in DNS. Fedora is implementing it, Microsofts implements it in Windows 7 and Windows Server 2008 R2.

Ubuntu must have good support.

See http://fedoraproject.org/wiki/Features/DNSSEC for affected packages etc.

Firefox 3 has done away with the useful security feature in Firefox 2 whereby secure encrypted connection were indicated with a visually prominent yellow addressbar.

This feature is really useful in quickly determining if a page into which I enter my personal info (login name, password etc.) is secure. Now I have to be alert enough to always keep an eye on some small icons which don't come to attention easily.

This feature can be restored, but its not straightforward and needs some tweaking of internals. Please bring this feature back, at least on the Ubuntu version.

I think it would be better to have an IM protocol that has these requirements.


When logging on from a different machine, both machines can be used at the same time for IM. So I could be logged on to an account from 2 places, and the messages would be received both places. So the other clients would have in their IP_to send list both locations.

Also simple encryption available.

File moving available (file size limit options).
Current IM standards should be realized.

Wouldn't that be cool to add to kopote , something that is better?

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.

Don't make the Private directory show up as an icon on my desktop (or make it an option to not display it). This just advertises the fact that I have hidden data. Also add the ability to create a private directory(ies) that are password protected instead of automatically decrypted on login. This is already possible using ecryptfs it just needs a GUI interface.

Most applications dont need full acces to your home and removable media (+ whatever you have write access to), in fact they dont need to be reading that stuff either, like any app you run can read your unencrypted firefox and pidgin passwords. There are sane ways to fix this problem.

For server applications the AppArmor (and not in ubuntu SELinux) try to define what a app needs to do and the minimum privileges it needs to do that. This is important for desktop applications for many doing solely this would be limiting. There needs to be some other way of setting permissions.

What do applications need to do? most have a configuration file, either ~/.application and/or /etc/application. and then most read a audio file, and then they create a odt with that audio file embedded. However unlike most server applications both these files can come and go from anywhere the user has access. In order to not limit users activities most removvable drives are fully accessable to users, even if they do have uid/gid awareness they are usually fully writable and accessable, but applications dont really need this uaually.

These apps allready pull up a system file menu, (nautilus, konquerer, or thunar) for both reading files and saving them. why not have the option to run these applications as unprivileged, (with access your X of course) and then have them access ability to read and/or write only with permission given by the action of selecting these files. (use security profiles and preferences to fine-tune)

Programs would only get access to set default config/profile files (rw), files you select for opening (r or rw depending on how it opens the file--intent shown in dialog), and files to save/modify, and folders to have full permissions over.

This could be tunable, designed to not get in peoples way, but all the same would greatly increase the security of many applications. firefox could access anything outside its profile or create files unless you told it to ( you already tell it, and creating files to default directories could be always allowed, just through group permissions.)