On 05/24/2012 01:18 PM, Guido Berhoerster wrote:

On 24.05.2012 11:25, Andreas Jaeger wrote:

...

Let's start a new thread to look a bit more at different roles.

I saw these two proposals:

Stefan Seyfried proposed a machine use case:

...

Having a few "presets" with the most common use cases, best accompanied with a short description is still a good idea IMHO. Maybe stuff like:

* "Admin configured server": you need the root password for all changes

-> basically like in good old times before polkit and friends: you'll

need to "su -" and then use yast or whatever to change stuff.

* "User configured laptop": you are allowed to connect to WiFi networks,> connect printers and install package updates with your user account. For adding software repositories and installing additional software, you'll need the root passowrd.

* "third preset": I have no idea what a third preset could be

Hans Witvliet seems to suggest user roles:

...

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.

I think that we need different settings for different users - even on the same machine. So, some kind of roles. I like the idea of having some configuration module for special purposes and also the idea of role-based administration - just fear it might be difficult to do.

AFAICS SELinux appears to be capable of implementing RBAC with MAC though it seems though that not even Redhat seems to makes use of that by default. Offering that with preconfigured roles for common tasks seems like a massive undertaking, extending YaST to assign roles to users in the user management modules is probably the easiest part.

Yeah, that's my fear as well. We need something practible. Fortunately we might not need to do everything at once ;)

...

So, my call for help again: Please give some proposals on what kind of roles/scenarios we want to offer - and be as precise on the different roles/scenarios as possible.

If you want to have a look at an existing implementation and its preconfigured roles, have a look at http://docs.oracle.com/cd/E19963-01/html/821-1456/rbacref-26.html . (Note that these are strictly speaking not roles but preconfigured "rights profiles" for common use cases consisting of capabilities which can be assigned either directly to users or to role accounts which users can assume after authentication.)

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 Thu, 2012-05-24 at 18:56 -0300, Claudio Freire wrote:

On Thu, May 24, 2012 at 3:54 PM, Robert Schweikert wrote:

...

...

* "Admin configured server": you need the root password for all changes

-> basically like in good old times before polkit and friends: you'll

need to "su -" and then use yast or whatever to change stuff.

This one should allow the admin to grant some users some rights, and instead of asking for root password, those users would be asked for their own.

That means that dedicated user-account, instead of groups. And the idea was, that a) if you are the single user & owner you don't want to be bothered with the concept of other accounts and certainly not the root-pwd (Linus variant) b) in a large company specific roles are assigned to certain users, Those users should only be troubled with their own pwd, and should never have access to neither root-pwd nor root-privileges. Dedicated accounts with their own pwd are a nightmare for an organisation. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.05.2012 01:24, schrieb Claudio Freire:

On Fri, May 25, 2012 at 8:07 PM, Hans Witvliet wrote:

...

b) in a large company specific roles are assigned to certain users, Those users should only be troubled with their own pwd, and should never have access to neither root-pwd nor root-privileges.

Dedicated accounts with their own pwd are a nightmare for an organisation.

What do you mean with that? I can only parse that sentence to mean all users should have the same password, which seems quite unlikely to be what you meant as that's nonsense.

I would read it as follows: If there is a dedicated account with it's own pwd for the administration of a service, it is not possible to see, who did the administration task. Nearly "everybody" could have logged in as the dedicated user, because many persons know the pwd. That is in contrast to the requirement, that you can find out who has done the administration task. Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.05.2012 12:03, schrieb Guido Berhoerster:

On 26.05.2012 10:16, Thomas Leineweber wrote:

...

I would read it as follows:

If there is a dedicated account with it's own pwd for the administration of a service, it is not possible to see, who did the administration task. Nearly "everybody" could have logged in as the dedicated user, because many persons know the pwd. That is in contrast to the requirement, that you can find out who has done the administration task.

That's not correct, su currently logs to syslog when you switch to another user and shells such as ksh93 provide auditing and per-user accounting facilities. Furthermore with a role account you'd disallow direct login for role accounts and restrict role assumption to users which have explicit authorization to do so.

I'm not sure how RBAC with SELinux works but e.g. in Solaris you can assign "rights profiles" (which are an aggregation of related privileges) even directly to a user instead of a role account who can then invoke commands with elevated privileges without an additional password but still with full auditing.

You are right, that su et al are logging the switches. I was talking about the possibility of a direct login to a role account without going through a personalized account before. Sorry for the confusion. Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 26, 2012 at 5:16 AM, Thomas Leineweber wrote:

I would read it as follows:

If there is a dedicated account with it's own pwd for the administration of a service, it is not possible to see, who did the administration task. Nearly "everybody" could have logged in as the dedicated user, because many persons know the pwd. That is in contrast to the requirement, that you can find out who has done the administration task.

Ah, yes, of course. Every admin would have their own user account, and that account would be a member of the group that has admin rights over the resource. That's how it has always been done in cli land, AFAIK, and that's how it ought to be done in the GUI too. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 26, 2012 at 3:09 PM, Guido Berhoerster wrote:

...

Every admin would have their own user account, and that account would be a member of the group that has admin rights over the resource. That's how it has always been done in cli land, AFAIK, and that's how it ought to be done in the GUI too.

No, it isn't how it's done today with policykit nor is that how it should be done for the complex and fine-grained access control policy that is required here. We need roles as groups are much too limited and unsuitable for numerous reasons. The most important are that they are too coarse, difficult and inefficient to administer and inherently less secure. Roles allow fine-grained and centralized assignment of permissions to operations (rather than just filesystem objects) and improve security since they need to be explicitly assumed, possibly requiring authentication.

But what stops policykit from using group information? I was not referring to filesystem-based permissions, I was talking about policykit checking group membership, as groups *are* roles. But I'm intrigued by your assertion that groups are inherently less secure. Why? What would you propose to use instead? (links would be fine) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dne 27.5.2012 19:05, Claudio Freire napsal(a):

On Sat, May 26, 2012 at 3:09 PM, Guido Berhoerster wrote:

...

...

Every admin would have their own user account, and that account would be a member of the group that has admin rights over the resource. That's how it has always been done in cli land, AFAIK, and that's how it ought to be done in the GUI too.

No, it isn't how it's done today with policykit nor is that how it should be done for the complex and fine-grained access control policy that is required here. We need roles as groups are much too limited and unsuitable for numerous reasons. The most important are that they are too coarse, difficult and inefficient to administer and inherently less secure. Roles allow fine-grained and centralized assignment of permissions to operations (rather than just filesystem objects) and improve security since they need to be explicitly assumed, possibly requiring authentication.

But what stops policykit from using group information?

I was not referring to filesystem-based permissions, I was talking about policykit checking group membership, as groups *are* roles.

Wouldn't we sooner or later run into the problem of the possible number of groups a user account can be member of? Not sure if it is an issue with current kernel, it's been ages since I last read kernel code... Jiri

But I'm intrigued by your assertion that groups are inherently less secure. Why? What would you propose to use instead? (links would be fine)

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dne 27.5.2012 17:02, Hans Witvliet napsal(a):

On Fri, 2012-05-25 at 20:24 -0300, Claudio Freire wrote:

...

On Fri, May 25, 2012 at 8:07 PM, Hans Witvliet wrote:

...

b) in a large company specific roles are assigned to certain users, Those users should only be troubled with their own pwd, and should never have access to neither root-pwd nor root-privileges.

Dedicated accounts with their own pwd are a nightmare for an organisation.

What do you mean with that? I can only parse that sentence to mean all users should have the same password, which seems quite unlikely to be what you meant as that's nonsense.

Perhaps mistaken, but i got the impression that privileges for maintaining , for instance a printer, would be given to a dedicated _user_ account (with its own pwd) instead of giving the privilege to a group. Although it might lead to a working situation, if you need dozens of accounts& pwd to do your job, the situation got worse instead of better/safer.

It will always depend on the granularity we need. If you would assign each user permission to each operation, it would turn into mess. What makes IMO more sense it to define more high-level roles, which would be assigned operations which they are allowed to perform, and assign the roles to users (multiple roles to a user, and multiple users having the role). Imagine on printing, you can have following operations: - reconfigure options of a printer queue - create a new printer queue - reorder the jobs in a queue - cancel a job (belonging to any user) and probably more. Then you can have high-level roles - printer admin (getting all of the above) - printer operator (getting the third and fourth) While we should come with sane defaults, this concept gives system admins a flexibility to define their roles. Jiri

And against gaining root privileges with sudo: A work somebody implented it, and it ended up in a huge mess. the person asked for it so he could start/stop apache and mysql and so on. but some weeks later on whe found out that was doing totally other things (changing network addresses, which caused a lot of trouble) (Probably he implemented it the wrong way, but still it leaves a bitter taste)

hw

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26.05.2012 09:22, Stefan Seyfried wrote:

Am 25.05.2012 12:13, schrieb Johannes Meixner:

...

Hello,

On May 24 11:25 Andreas Jaeger wrote (excerpt):

...

Let's start a new thread to look a bit more at different roles.

I saw these two proposals:

Stefan Seyfried proposed a machine use case:

...

Having a few "presets" with the most common use cases, best accompanied with a short description is still a good idea IMHO. Maybe stuff like:

* "Admin configured server": you need the root password for all changes

-> basically like in good old times before polkit and friends: you'll need to "su -" and then use yast or whatever to change stuff.

* "User configured laptop": you are allowed to connect to WiFi networks, connect printers and install package updates with your user account. For adding software repositories and installing additional software, you'll need the root passowrd.

What exactly does it mean "you are allowed"?

Can the user do particular configuration changes without entering any password?

Not necessarily. They might need to enter their own password (sudo like). But for WIFI, even this might feel strange (somewhen in the past I managed to change the polkit stuff in the KDE gui for it by clueless clicking so that I am allowed to connect to WiFi networks now and so I missed all the fun in 12.1. However, most of the time I can just connect but one out of ten tries, some gnome-polkit-agent or such asks me a password. Of course it does not tell me which password. On the second try I then find out that it is my password it is asking for...).

I'm pretty sure you can configure policykit to authorize e.g. local users to do all of the above without asking for a password. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On May 26 12:11 Guido Berhoerster wrote (excerpt):

On 25.05.2012 12:13, Johannes Meixner wrote:

...

Proposal for a "third preset":

* "Single password protected machine" Same as the "Admin configured server" but the root password is the same as the user password. ...

This is already the default.

Then I do not understand what the whole discussion is about. If the root password is by default the same as the user password, the user can do everything - he only needs to enter the password. If the root password is by default the same as the user password why does someone complain a normal user cannot set up something? Please note that I am not a destop user (I use X with a plain window manager and a root shell when I need to do something as root) so that I don't know about possibly special behaviour of desktop environments. 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

Hello, On May 29 13:44 Marcus Meissner wrote (excerpt):

On Tue, May 29, 2012 at 11:20:09AM +0200, Johannes Meixner wrote:

...

On May 26 12:11 Guido Berhoerster wrote (excerpt):

...

On 25.05.2012 12:13, Johannes Meixner wrote:

...

Proposal for a "third preset":

* "Single password protected machine" Same as the "Admin configured server" but the root password is the same as the user password. ...

This is already the default. ... This is the default that YAST currently suggests during installation.

This basically makes the there configured first Desktop User the "knowledgeable admin" type of user.

Then the crucial final question is: Did Linus set up the user account for his daughter as "first Desktop User"? If not the ultimate crucial final question would be: Why did he fail to do so? 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 05/29/2012 02:57 PM, Marcus Meissner wrote:

On Tue, May 29, 2012 at 02:42:22PM +0200, Johannes Meixner wrote:

...

Hello,

On May 29 13:44 Marcus Meissner wrote (excerpt):

...

On Tue, May 29, 2012 at 11:20:09AM +0200, Johannes Meixner wrote:

...

On May 26 12:11 Guido Berhoerster wrote (excerpt):

...

On 25.05.2012 12:13, Johannes Meixner wrote:

...

Proposal for a "third preset":

* "Single password protected machine" Same as the "Admin configured server" but the root password is the same as the user password. ...

This is already the default. ... This is the default that YAST currently suggests during installation.

This basically makes the there configured first Desktop User the "knowledgeable admin" type of user.

Then the crucial final question is:

Did Linus set up the user account for his daughter as "first Desktop User"?

If not the ultimate crucial final question would be:

Why did he fail to do so?

as far as I understand he does not want his daughter to change software repos, delete or install random packages, or add new users.

He just wants that she can add a printer, but its not even clear if this was a USB or Samba or IPP printer.

So he does not want to give her full root rights.

less than full and selectable root powers is what sudo is all about, right? so he has (as the administrator) the ability to set it exactly as he said he wanted it....or, did i miss something? -- dd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29.05.2012 15:36, Marcus Meissner wrote:

On Tue, May 29, 2012 at 03:34:27PM +0200, DenverD wrote:

...

On 05/29/2012 02:57 PM, Marcus Meissner wrote: less than full and selectable root powers is what sudo is all about, right?

If this would all be commandline root tools ... Yes.

But sadly, we are in 2012.

Things get configured and setup using DBUS, PolicyKit and friends ... but not sudo.

At least on RHEL sudo is patched to support switching roles when using SELinux RBAC, PolicyKit can easily sit on top of an RBAC implementation, in fact libpolkit on Solaris is only a shim on top of the native RBAC implementation. So it is possible to put the pieces together and get a unified RBAC implementation on Linux as well based on SELinux or AppArmor, it's just that nobody seems to bother implementing it. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On May 29 14:57 Marcus Meissner wrote (excerpt):

So he does not want to give her full root rights.

In Linus particular case he gives her full hardware access (he gives her the laptop) but at the same time he does not want to give her full root rights? I cannot imagine that Linus expects that out-of-the-box any normal user has the right e.g. to add/modify print queues. I don't think it is possible that the current default borderline between normal user rights and administrator rights can be moved towards more rights for normal users (towards more convenience) and still keep the system secure. I think if a normal user gets particular administrator rights, it basically means in the end that this normal user gets a more or less complicated way to somehow gain full administrator rights. There might be a few exceptional cases or even bugs, but in general I think the current default borderline is intentionally where it is because this is exactly what keeps a system secure. E.g.: Allow a normal user to add/modify print queues means to allow him to eavesdrop on every print job content which means that he is allowed to read root's print jobs which means he may collect sufficient information to somehow get full administrator rights, compare https://bugzilla.novell.com/show_bug.cgi?id=752454#c3 I am not against giving a normal user a particular administrator right but the one who allowes it (usually root) must know that this means he must trust the user who gets the particular administrator right. 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

Hello, On May 29 12:02 James Knott wrote (excerpt):

Actually, in the corporate world, it's quite common to allow employees to add/delete printers. That was certainly the case when I worked at IBM and also with the insurance company I've been doing some work

Do you really mean it as follows: "In the corporate world, it's quite common to allow employees to add/delete printers in the corporate network which are used by all employees in the corporate network." Or do you probably mean it as follows: "In the corporate world with a Windows-like printing environment, it's quite common to allow employees to add/delete printers on their own workstations so that the employee can submit print jobs from his own workstation to the corporate print server." Could you provide some more details about the printing environment when you worked at IBM and also in the insurance company. In particular: Was there a CUPS server as corporate print server? I assume in both cases it was a Windows-like printing environment. In this case printers must be usually set up on each individual client system so that the client system can submit print jobs with printer-specific data to the corporate print server. See http://en.opensuse.org/SDB:Printing_via_SMB_%28Samba%29_Share_or_Windows_Sha... ----------------------------------------------------------------- Printing via SMB (Samba) Share or Windows Share ... When a printer is addressed by a Linux host by means of the SMB protocol, this is merely for data transfer. The SMB host does not convert the print data from the applications (e.g., PostScript) to printer-specific data. Therefore, the filtering must take place on the Linux host, which requires a complete print system on the Linux host. A queue with filtering must be set up on the Linux host. After the data is filtered, the queue sends the printer-specific data to the SMB share. The SMB share receives the printer-specific data and forwards it to the printer associated with the share. ----------------------------------------------------------------- (therein you can replace "Linux host" with "any client system") and see http://en.opensuse.org/SDB:Printing_from_Windows_to_Linux ----------------------------------------------------------------- Differences in Printing between Windows and Linux When printing via network with Windows, the most usual case is for the client system to run a driver for the printer which converts the original data (plain text, Microsoft Office documents, or other proprietary formats) into printer-specific format and then send the converted data via network to a printer share on a Windows print server via the SMB protocol. The print server then sends the printer-specific data to the printer. Usually the Windows print server does only the spooling (plain data buffering and transfer to the printer device). The filtering (conversion into printer-specific format) is done on the client system, so printer drivers must be installed on the client systems. When printers are added or replaced, users must install the matching drivers on their laptops or workstations before they can print. Or an automatism installs drivers automatically from a Windows print server on the client systems - provided the users of the client systems like it when an automatism installs software on their laptops or workstations which means that the users must trust such "foreign" software ("how to hijack laptops of innocent guests when they like to print in our environment"). With UNIX/Linux printing, client systems send the original data (plain text, PostScript, PDF, or JPEG) to the CUPS print server, specifically to a print queue via the IPP protocol. The CUPS server then runs a driver for the printer which converts the data into printer-specific format and sends the converted data to the printer device (see Concepts printing http://en.opensuse.org/Concepts_printing). The CUPS server does both the spooling and filtering. This means that client systems don't need to know about differences in printer models and don't need printer-specific drivers. The CUPS server handles the specific details of the printer hardware. The advantage is that end-users can connect laptops and desktops to a network where a CUPS server is running, run their own cupsd on the laptop or desktop, and print immediately. For additional detail, see "Intrinsic Design of CUPS for Printing in the Network" at SDB:CUPS in a Nutshell http://en.opensuse.org/SDB:CUPS_in_a_Nutshell ----------------------------------------------------------------- Finally it really helps to read the wiki page which is especially set up for this kind of discussion: http://en.opensuse.org/openSUSE:Security_use_cases in particular: ----------------------------------------------------------------- Using a remote printer Usecase: Jana takes her laptop to her office and wants to print on one of the office printers. If there is a CUPS server in the office network that advertises its printers via so-called "CUPS Browsing", the cupsd on the local system (if the ports for CUPS are open in the firewall on the local system) would recognize the printers so that there is nothing to set up for the user on her local system. Printing in a Windows network: Usually this means to access a printer device via a SMB printer share. In this case, the local (client) system must usually submit ready-made printer specific data to the SMB share. Therefore, on the client system, a printer driver must usually run and that means the user must usually add a new local printer on her local system for printing in a Windows network. ----------------------------------------------------------------- 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 05/29/2012 08:57 AM, Marcus Meissner wrote:

On Tue, May 29, 2012 at 02:42:22PM +0200, Johannes Meixner wrote:

...

Hello,

On May 29 13:44 Marcus Meissner wrote (excerpt):

...

On Tue, May 29, 2012 at 11:20:09AM +0200, Johannes Meixner wrote:

...

On May 26 12:11 Guido Berhoerster wrote (excerpt):

...

On 25.05.2012 12:13, Johannes Meixner wrote:

...

Proposal for a "third preset":

* "Single password protected machine" Same as the "Admin configured server" but the root password is the same as the user password. ...

This is already the default. ... This is the default that YAST currently suggests during installation.

This basically makes the there configured first Desktop User the "knowledgeable admin" type of user.

Then the crucial final question is:

Did Linus set up the user account for his daughter as "first Desktop User"?

If not the ultimate crucial final question would be:

Why did he fail to do so?

as far as I understand he does not want his daughter to change software repos, delete or install random packages, or add new users.

He just wants that she can add a printer, but its not even clear if this was a USB or Samba or IPP printer.

So he does not want to give her full root rights.

That is my understanding as well. It is really about the 1 user + 1 admin use case, i.e. it is a multiuser system with restriction that the root user almost never uses the machine. Later, 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