Very good points . It seems I have a lot more to read on linux security . On Thu, 2013-10-10 at 19:01 +0100, Simon McVittie wrote: > On 10/10/13 18:12, p10 wrote: > > That's my current "security setup" - a user account that I use for > > everything , and 'su' into root with a password I don't keep stored > > anywhere > > If you type your root password into a gnome-terminal running with user > privileges, a shell running with user privileges, etc., then your user > account is root-equivalent to a determined attacker (for instance, other > user processes could ptrace the gnome-terminal or shell, or put a > keylogging 'su' wrapper in the $PATH). > > If you want real privilege separation, you'll need to log in as root (or > as a separate administrative account) via something more privileged than > your user account (e.g. gdm, or getty(8)/login(1) on a text-mode virtual > console). > > > if a root service unlocks > > the key-ring for all the user-space programs - there's no point in > > having the system in the first place . So that is a problem that if I'm > > not mistaken stands with the current setup too - if you unlock the > > keyring every user-space app can access the stored passwords . > > gnome-keyring does not protect you from your own user session. Security > is meaningless without a security model, and gnome-keyring's security > model is <https://wiki.gnome.org/GnomeKeyring/SecurityPhilosophy>. > > When applications within a user session can be protected from each > other, it will make sense to develop a new security model. I don't think > we're there yet. > > S > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
