Re: [opensuse-factory] Security or Convenience? Defining a better policy
Am 05/22/12, schrieb Claudio Freire
On Tue, May 22, 2012 at 11:00 AM, Bryen M Yunashko
wrote: eg: I would like YaST2 never ask me root password to install software, since it's my laptop and no one else can use it...but it'll surely be banned in a security expert's eyes, and I don't know how to adjust it for myself
I agree that some basic functionalities shouldn't require passwords. Obvious are adding wifi networks or printer connections. However, I still greatly appreciate requiring a password even on my own machine for software installations. If anything, it becomes a gentle reminder to me that I must exercise my abilities with caution.
But that's the point: "require passwords" doesn't mean "require root password".
As sudo asks *your* password, those tools that handle wifi, printers and such should also ask the user's password, and check whether the user has permission to administer wifi, printers, and such.
We have sudo. Can't sudo be used for this? I imagine not because it's a dbus issue. But then, dbus should be extended to support sudo-like handling of permissions.
Also, installing software from configured repos is not the same, security-wise, to installing software from source or from untrusted repos.
Thats what polkit is for. You can give permissions on a fine granular level (and recently, the possibility to define permissions hierarchically has been added), and the default for the "admin" privilege level can be changed to the wheel group with a one-liner. Unfortunately, there is no nice interface to change permissions, last time I checked the KDE policy configurator it did not work as expected. Regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, May 22, 2012 at 2:28 PM, "Stefan Brüns"
Am 05/22/12, schrieb Claudio Freire
: On Tue, May 22, 2012 at 11:00 AM, Bryen M Yunashko
wrote: eg: I would like YaST2 never ask me root password to install software, since it's my laptop and no one else can use it...but it'll surely be banned in a security expert's eyes, and I don't know how to adjust it for myself
I agree that some basic functionalities shouldn't require passwords. Obvious are adding wifi networks or printer connections. However, I still greatly appreciate requiring a password even on my own machine for software installations. If anything, it becomes a gentle reminder to me that I must exercise my abilities with caution.
But that's the point: "require passwords" doesn't mean "require root password".
As sudo asks *your* password, those tools that handle wifi, printers and such should also ask the user's password, and check whether the user has permission to administer wifi, printers, and such.
We have sudo. Can't sudo be used for this? I imagine not because it's a dbus issue. But then, dbus should be extended to support sudo-like handling of permissions.
Also, installing software from configured repos is not the same, security-wise, to installing software from source or from untrusted repos.
Thats what polkit is for. You can give permissions on a fine granular level (and recently, the possibility to define permissions hierarchically has been added), and the default for the "admin" privilege level can be changed to the wheel group with a one-liner.
Unfortunately, there is no nice interface to change permissions, last time I checked the KDE policy configurator it did not work as expected.
Regards,
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already? We're still thinking hypotheticals here IMO and not addressing very specific items. Some kind of list with 3 columns: 1) Yes keep secure, 2) Maybe and 3) Duh! open it up!. :-) Bryen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, May 22, 2012 at 2:46 PM, Bryen M Yunashko
We're still thinking hypotheticals here IMO and not addressing very specific items. Some kind of list with 3 columns: 1) Yes keep secure, 2) Maybe and 3) Duh! open it up!. :-)
In that vein, it should be noted that even printers are security-critical. Imagine an attacker could reconfigure your printers (ie: by making you run some malicious javascript or something like that) so that every document you print goes to an external server - he'd know everything you do, which would be a *very* serious breech in an enterprise context. Same goes for wifi and network in general. So even if users can be given permission to change printer/network settings, it ought to require explicit authorization in the form of a password prompt (prompting the user's password, not root's). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/22/2012 01:46 PM, Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
The wiki page Andreas posted when starting the thread?
We're still thinking hypotheticals here IMO and not addressing very specific items.
I think the wiki page is pretty concrete, but yes the discussion did not, unfortunately, center around the work Andreas, Ludwig and Marcus have already done. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2012-05-22 at 14:07 -0400, Robert Schweikert wrote:
On 05/22/2012 01:46 PM, Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
The wiki page Andreas posted when starting the thread?
Yes, you're correct. As soon as I sent that message, I told myself "WTF dude? Pay attention!" :-) Then I thought hmm.. let's see how quickly someone catches on to the fact that I was at another planet at the time. Congrats for winning. We'll send you a coupon for a free download of openSUSE 12.2 when it comes out. :-D Bryen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2012-05-22 at 12:46 -0500, Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
Excuse me for jumping into the middle of the thread.. But does it have to be binary: either-or-not? I would rather see a more granular approach... How about defining an "admin" group. You should be able to add some users to that group. And all of those "admins" should be able to manage printers, wifi-stuf, and updates. Or even better: create multiple groups: each for its own group of applications. So some users might be able to fiddle with wifi, but nothing else, while others are only allowed to do updates For an ordinary home-users, the default user should be member of all those admin groups, while on office-laptops, one should be able to do wifi and printers, but remains properly shielded from installing malware. I think one should be able to create a reasonable list of allications that deserve there own admin-group: software (general) updates network (general) wifi printers apache database ldap mail Hans -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On May 22 21:41 Hans Witvliet wrote (excerpt):
on office-laptops, one should be able to do wifi and printers
In other words: On office-laptops, one should be able to do "print job phishing", see http://en.opensuse.org/openSUSE:Security_use_cases#Printer I am not against it because if someone is allowed to connect his own laptop to a network, he can eavesdrop on the network and he can also fake any server machine in the network (except additional network switch hardware limits the user's network access), see http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, May 22, 2012 21:41:07 Hans Witvliet wrote:
On Tue, 2012-05-22 at 12:46 -0500, Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
Excuse me for jumping into the middle of the thread..
But does it have to be binary: either-or-not? I would rather see a more granular approach...
How about defining an "admin" group. You should be able to add some users to that group.
And all of those "admins" should be able to manage printers, wifi-stuf, and updates.
Or even better: create multiple groups: each for its own group of applications. So some users might be able to fiddle with wifi, but nothing else, while others are only allowed to do updates
For an ordinary home-users, the default user should be member of all those admin groups, while on office-laptops, one should be able to do wifi and printers, but remains properly shielded from installing malware.
I think one should be able to create a reasonable list of allications that deserve there own admin-group:
software (general) updates network (general) wifi printers apache database ldap mail
What about the following if you're the apache admin: The yast2 apache module might need to install other packages - should this be allowed or not? You could add all those roles but I fear it makes administration more difficult. How can we setup in an easy way the most use cases? We still might need for the last 10% esoteric options a config file to change the defaults but what is the normal way? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2012-05-23 at 14:23 +0200, Andreas Jaeger wrote:
On Tuesday, May 22, 2012 21:41:07 Hans Witvliet wrote:
On Tue, 2012-05-22 at 12:46 -0500, Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
Excuse me for jumping into the middle of the thread..
But does it have to be binary: either-or-not? I would rather see a more granular approach...
How about defining an "admin" group. You should be able to add some users to that group.
And all of those "admins" should be able to manage printers, wifi-stuf, and updates.
Or even better: create multiple groups: each for its own group of applications. So some users might be able to fiddle with wifi, but nothing else, while others are only allowed to do updates
For an ordinary home-users, the default user should be member of all those admin groups, while on office-laptops, one should be able to do wifi and printers, but remains properly shielded from installing malware.
I think one should be able to create a reasonable list of allications that deserve there own admin-group:
software (general) updates network (general) wifi printers apache database ldap mail
What about the following if you're the apache admin:
The yast2 apache module might need to install other packages - should this be allowed or not?
You should have different roles for installing software and one for managing Apache. Both roles however can be assigned to a single person. (and i presume he would also get the rights for doing things with mysql) But i you want to seperate those responsibilities: you can!
You could add all those roles but I fear it makes administration more difficult. How can we setup in an easy way the most use cases? We still might need for the last 10% esoteric options a config file to change the defaults but what is the normal way?
Shouldnt be too hard for the YaST-guru's ;-) Sort of matrix. In the end your security model has three options: 1) For home-users (or general: single responsibility) end user is allowed to do all. (what Linus wanted) 2) the old-fashioned way, where you need to be root for everything 3) above mentoned proposal, where the privilige for any particular part is assigned to a specific group, and where the utmost highest admin, can assign those priviliges to any user. Fits nice in "the least privilige" model, easier to maintain security in a large organiation. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hans Witvliet wrote:
For an ordinary home-users, the default user should be member of all those admin groups, while on office-laptops, one should be able to do wifi and printers, but remains properly shielded from installing malware.
I think one should be able to create a reasonable list of allications that deserve there own admin-group:
software (general) updates network (general) wifi printers apache database ldap mail
--------------------- In order to better integrate SuSE as Windows Samba DC's, it might be a good idea to use names and ID's associated with Windows's groups. Some examples from my own /etc/group file: We don't need to use all of these groups, but we might consider 'trying' to reserve them at some 'range' (ideally at offsets of 10000, or maybe 1000000 Some useful and potentially useful groups (with many examples, but likely NOT a thorough list -- and also it would be likely that many of these would only be needed in more complex setups: (names taken verbatim from published MS documents -- spaces work fine -- backslashes also work -- they are literals, not quoting characters) Cert Publishers:!:517:root -- those who can *create( 'signing' certs for a domain (or sub domain) Schema Admins:!:518:root -- LDAP? CIM? Enterprise Admins:!:519:root:MyDomain\lawalsh domain-wide root Group Policy Creator Owners:!:520:root Polkit editors/creators Administrators:!:544:root,Administrator,Domain Admins,Enterprise Admins machine-level root Account Operators:!:548:backup,root root level access on local machine Server Operators:!:549: start/stop services; restart machine Print Operators:!:550: Add / modify print devices & queues Backup Operators:!:551:backup who can run backup and restore (which need DAC override + SET_LABEL ) Remote Desktop Users:!:555:root Those who can login remotely to a machine and get a full X-server (xrdp, remote X (xdmcp)) (might be different than those who can run ssh) Network Configuration Operators:!:556: if/ip commands + config -- firewall... etc... Distributed Com User:!:562: A group to control/allow access to RPC resources apart from per-user access Web Services:!:568: apache/lighttpd -- or any other web server... Cryptographic Operators:!:569: Those who can add new certs (not create them) to a machine or group -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hey, On 05/22/2012 07:46 PM, Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
Please read the page mentioned in the first mail of this thread :-) Its an exhaustive list of use-cases (items) with reasoning why (or why not) it should be protected. How about discussing the use-cases that are there and add missing ones? Henne -- Henne Vogelsang, openSUSE http://www.hennevogel.de Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, May 22, 2012 19:46:00 Bryen M Yunashko wrote:
On Tue, 2012-05-22 at 14:40 -0300, Claudio Freire wrote:
So I'd kindly suggest that a yast module for that, and sensible defaults, would be a priority.
Perhaps it would be a better approach here if we came up with a comprehensive list of items that need to remain security-protected versus not needed. Or does such a list exist somewhere already?
Did you check the wiki page? IT contains a long list..
We're still thinking hypotheticals here IMO and not addressing very specific items. Some kind of list with 3 columns: 1) Yes keep secure, 2) Maybe and 3) Duh! open it up!. :-)
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 22. Mai 2012, 19:28:50 schrieb Stefan Brüns:
Thats what polkit is for. You can give permissions on a fine granular level (and recently, the possibility to define permissions hierarchically has been added), and the default for the "admin" privilege level can be changed to the wheel group with a one-liner.
I agree that while it is good to think about defaults it is impossible to make them fit everybody, especially since openSUSE can be used in totally different environments. Hence the only real solution is to enable the user to configure his computer to his needs, easily, i.e. via a GUI.
Unfortunately, there is no nice interface to change permissions, last time I checked the KDE policy configurator it did not work as expected.
If I remember correctly the problem is that it works on some files which are replaced with the next update. Instead it has to copy those files and put them where user-defined policies are stored. I think some permissions, e.g. adding printers, are not even listed in the Polkit module – not sure though whether that is an openSUSE or KDE issue. I suggest to spend time on fixing and improving existing interfaces and push those fixes upstream where others can profit and add to them. With a new YaST module openSUSE is on its own and needs yet another maintainer with no hope of others contributing. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
"Stefan Brüns"
-
Andreas Jaeger
-
Bryen M Yunashko
-
Claudio Freire
-
Hans Witvliet
-
Henne Vogelsang
-
Johannes Meixner
-
Linda Walsh
-
Robert Schweikert
-
Sven Burmeister