I played a couple of days with PAM (Pluggable Authentication Modules). I do not have big experience in this area and want to know your opinion about my ideas.
*** PAM short explanation ***
PAM <From PAM for Linux documentation> Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users. It is possible to switch between the authentication mechanism(s) without (rewriting and) recompiling a PAM-aware application. Indeed, one may entirely upgrade the local authentication system without touching the applications themselves. </From PAM for Linux documentation>
PAM-aware application requests authorization using predefined id - PAM service name. System administrator configures the application authorization bas
PAM service name identifies set of authorization parameters.
For more information see http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
Note, that application does not see parameters of the authorization process, e.g password, Windows NT domain name, authorization server. The application only knows user name and service name.
*** PAM and Wine ***
Integration with PAM allows Wine to provide authentication services for Windows applications through Windows API. PAM has modules for native Unix authentication, Samba, flat files, relational databases.
Example:
Windows ftp server application, running under Wine can be configured to use any method of authorization, provided by PAM - Windows domain, flat file, relational database. This authorization can be made different from the authorization, required to run wine itself and different from default authorization for Wine applications.
Following PAM services can be configured for Wine from more general to more detailed:
* PAM service for Wine itself
* Default Wine Applications service - default service which provides authentication for Windows applications. Exact name of the service will be specified in the Wine configuration is used if not specified.
* Application-Specific Service Name specified in the AppDefaults section of the .wine/config file for given application. Default Application service is used if not specified
Questions, problems:
Do we have requirement for wineserver to work across user boundaries? If no, then we probably don't need PAM service for Wine itself.
As you see Wine won't know anything about NT domains. I was thinking about passing service name through domain name parameter.
Example:
Call LogonUser accepts lpszDomain parameter. Instead of the domain name DOMAIN1 user provides to the application PAM service name SERVICE1. PAM service SERVICE1 is configured to use Samba module for authentication in NT domain DOMAIN1.
PAM provides authorization and nothing else. To get more information from the authorization provider you should access it directly. E.g. with PAM only it is impossible to get list of users, groups from Windows NT domain, which user belongs to which group. Even more, it is impossible to know that some PAM service underneath uses NT domain and name of this domain.
I can't imagine how to implement with PAM scenario like this - Windows application gets list of users belonging to some group, presents it to the user, then does authentication for one of user names. On other hand it is possible to do that with Samba.
It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine. The downside - this is much more complex approach than PAM.
Andriy
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
--- Andriy Palamarchuk apa3a@yahoo.com wrote: [skipped]
I can't imagine how to implement with PAM scenario like this - Windows application gets list of users belonging to some group, presents it to the user, then does authentication for one of user names. On other hand it is possible to do that with Samba.
It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine. The downside - this is much more complex approach than PAM.
Discussion on the PAM mailing list along the same lines: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=12488e03f9...
Andriy
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Am Fre, 2002-09-20 um 21.25 schrieb Andriy Palamarchuk:
I played a couple of days with PAM (Pluggable Authentication Modules). I do not have big experience in this area and want to know your opinion about my ideas.
*** PAM and Wine ***
Integration with PAM allows Wine to provide authentication services for Windows applications through Windows API. PAM has modules for native Unix authentication, Samba, flat files, relational databases.
Did you have a look at the LogonUser() implementation I submitted last week?
Questions, problems:
Do we have requirement for wineserver to work across user boundaries?
I think we'll ultimately have to, although that's certainly a long-term-future project. wineserver and the ntdll would need to have a concept of security tokens etc., and we would need to figure out a way to e.g. change personality with CreateProcessAsUser() without compromising underlying Unix security.
AFAICT, this would mean substantial additions to the core of wine, and must be done very carefully. For CreateProcessAsUser(), for example, wine would need to have the CAP_SETUID capability, although we certainly don't want to run wine with root privileges.
If no, then we probably don't need PAM service for Wine itself.
As you see Wine won't know anything about NT domains. I was thinking about passing service name through domain name parameter.
I strongly disagree. I think the domain should be the domain, and nothing else.
This is the approach in my LogonUser() implementation ("user", "domain") -> "domain\user", and do Samba authentication with that user name.
This is also the syntax you use when authorizing yourself with smbclient or smbmount in large NT networks with several domains.
The beautiful aspect of this is that the pam_winbind module authenticates against a Windows PDC for you, which is what the Windows application expects.
Call LogonUser accepts lpszDomain parameter. Instead of the domain name DOMAIN1 user provides to the application PAM service name SERVICE1. PAM service SERVICE1 is configured to use Samba module for authentication in NT domain DOMAIN1.
I think it would be more reasonable to put a "pam servicename" entry into the registry for each application that uses authentification. If there is none, we'd use the standard "wine" service, and if that doesn't exist either, PAM would automatically use "other" which is usually very restricted.
PAM provides authorization and nothing else. To get more information from the authorization provider you should access it directly. E.g. with PAM only it is impossible to get list of users, groups from Windows NT domain, which user belongs to which group. Even more, it is impossible to know that some PAM service underneath uses NT domain and name of this domain.
But you can do these things with nss switch. With windbind properly configured, getpwnam() and friends will work with the PDC through winbind.
The whole picture looks like this:
For authentification, account and session setup: wine -> PAM -> pam_winbind -> winbindd -> PDC
For user/group info: wine -> NSS switch -> nss_winbind -> winbindd -> PDC
I can't imagine how to implement with PAM scenario like this - Windows application gets list of users belonging to some group, presents it to the user, then does authentication for one of user names. On other hand it is possible to do that with Samba.
PAM must use samba, that's the point.
The main reason to use PAM is that wine should not (I am positive about that) work around the "native" Unix authorization mechanisms that PAM provides.
It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine.
No, please - let's not reinvent the wheel!
The downside - this is much more complex approach than PAM.
Exactly.
I think what causes confusion is that PAM only covers part of what belongs into "security management" in NT. It's main functionality is to provide a transparent authentication mechanism.
However, it does this job very well, and it can easily be complemented by other components (see above) to do the rest.
Martin
--- Martin Wilck Martin.Wilck@fujitsu-siemens.com wrote:
Integration with PAM allows Wine to provide authentication services for Windows applications through Windows API. PAM has modules for native
Unix
authentication, Samba, flat files, relational databases.
Did you have a look at the LogonUser() implementation I submitted last week?
Yes, I reviewed it, thank you for the example.
As you see Wine won't know anything about NT
domains.
I was thinking about passing service name through domain name parameter.
I strongly disagree. I think the domain should be the domain, and nothing else.
Ok
But you can do these things with nss switch. With windbind properly configured, getpwnam() and friends will work with the PDC through winbind.
As I uderstand from your explanation we can use PAM for authentication and standard Unix calls for other user management needs, is this correct?
Andriy
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Am Mon, 2002-09-23 um 17.08 schrieb Andriy Palamarchuk:
As I uderstand from your explanation we can use PAM for authentication and standard Unix calls for other user management needs, is this correct?
I think so. Had no time for a proof-of-concept implementation yet. But if windbindd is configured, you can use standard Unix commands to get group/user info, like this:
$ id 'synergy.dom\wilck' uid=10050(SYNERGY.DOM\wilck) gid=10005(SYNERGY.DOM\cc_user) Gruppen=10005(SYNERGY.DOM\cc_user)
Note: this info comes from our PDC. If you do an 'ltrace' on the id(1) command, you see that it calls getpwnam(), getpwuid(), getgrent() and friends only.
Martin
On Mon, 2002-09-23, 11.28, I wrote:
It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine.
No, please - let's not reinvent the wheel!
I have been thinking about this a bit further - perhaps I was wrong in the first place.
There are two aspects I neglected:
* NT security and NETAPI have a broader scope than PAM + NSS combined. * Unicode.
What we discussed so far were user authentification and user/group/hostname lookups. Of course, this is only a small subset of the NETAPI interface.
winbindd itself can do more, for example lookup a user SID on the remote server. Even more functionality would be available by linking directly against the Samba library libsmbclient.so, but we can't do that due to license issues.
Perhaps we should think about an extended winbindd that would follow similar lines as the current Samba winbindd (talk to Unix Apps through a Unix domain socket), but offer even more functionality that isn't implemented in winbind because the information passed by such calls makes no sense to Unix applications.
AFAICS, winbind does not expect applications to pass Unicode strings for user names, domain names, etc., either. Our winbindd replacement would need to be able to handle that, too; otherwise we wouldn't be able to pass Unicode strings from a Windows application to a Windows server without corruption.
The winbindd replacement would need to be GPLd in order to link against Samba libraries.
That way wine would be able to use the existing samba functionality. If we had such a daemon, we could to reconsider the PAM and NSS routes because these probably won't be Unicode aware for some time to come (correct me if I'm wrong).
Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them.
Martin
On Tue, Sep 24, 2002 at 05:53:20PM +0200, Martin Wilck wrote:
What we discussed so far were user authentification and user/group/hostname lookups. Of course, this is only a small subset of the NETAPI interface.
winbindd itself can do more, for example lookup a user SID on the remote server. Even more functionality would be available by linking directly against the Samba library libsmbclient.so, but we can't do that due to license issues.
Perhaps we should think about an extended winbindd that would follow similar lines as the current Samba winbindd (talk to Unix Apps through a Unix domain socket), but offer even more functionality that isn't implemented in winbind because the information passed by such calls makes no sense to Unix applications.
AFAICS, winbind does not expect applications to pass Unicode strings for user names, domain names, etc., either. Our winbindd replacement would need to be able to handle that, too; otherwise we wouldn't be able to pass Unicode strings from a Windows application to a Windows server without corruption.
The winbindd replacement would need to be GPLd in order to link against Samba libraries.
That way wine would be able to use the existing samba functionality. If we had such a daemon, we could to reconsider the PAM and NSS routes because these probably won't be Unicode aware for some time to come (correct me if I'm wrong).
Er, um... PAM and NSS will *never* be Unicode-aware. There's no reason for either of these APIs to care about the character set of the input values (though individual modules may have reasons to care). And if you mean UCS2-capable, don't expect for that to happen, either: Unix already has a standard Unicode encoding, and it supports all 32-bits of the codepoint space and does so without breaking traditional C string handling, thankyouverymuch.
Regardless, I agree that PAM and NSS are probably not what you're looking for. What you're probably *really* looking for is a complete DCE/RPC implementation for Unix, of the sort that dcerpc.org aims to provide. I know from talking with some of the Samba-TNG developers that they, at least, are eager for Wine to work with them to standardize on a common set of RPC implementations. :)
Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them.
Not what winbindd is meant for, really.
Steve Langasek postmodern programmer
Am Mit, 2002-09-25 um 03.43 schrieb Steve Langasek:
Er, um... PAM and NSS will *never* be Unicode-aware. There's no reason for either of these APIs to care about the character set of the input values (though individual modules may have reasons to care).
Can't follow you: if some modules do care, the core PAM/NSS must handle the character sets somehow in order to pass strings right, or not?
And if you mean UCS2-capable, don't expect for that to happen, either: Unix already has a standard Unicode encoding, and it supports all 32-bits of the codepoint space and does so without breaking traditional C string handling, thankyouverymuch.
If these tools properly supported ISO10646, UTF-8, or equivalent, we'd be set.
Regardless, I agree that PAM and NSS are probably not what you're looking for. What you're probably *really* looking for is a complete DCE/RPC implementation for Unix, of the sort that dcerpc.org aims to provide. I know from talking with some of the Samba-TNG developers that they, at least, are eager for Wine to work with them to standardize on a common set of RPC implementations. :)
What I am _not_ looking for is Wine working around Unix security mechanisms. Even if Wine had a well-designed, well-tested internal security mechanism (which isn't the case AFAICT) this would mean running Wine on any Unix system would be dangerous. Thus proper use of PAM is IMO mandatory. If we loose out on character set support, bad luck for some environments, but no reason to have an independent security authority on a Unix system.
Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them.
Not what winbindd is meant for, really.
winbind makes a small subset of Windows RPC calls available to Unix applications. Windows applications running under Wine will make sense (and perhaps need) a larger subset of these calls. An interface like winbind's, using Samba libs internally, would be by far the easiest way for Wine to to offer this service to applications.
Certainly winbind wasn't written with Wine in mind. The question is not what winbind was meant for, but whether its authors would agree to widen its scope. If not, wine must go a different route, e.g. by writing a compatible replacement (aka "winebind" :-).
Martin
On Wed, Sep 25, 2002 at 02:34:34PM +0200, Martin Wilck wrote:
Er, um... PAM and NSS will *never* be Unicode-aware. There's no reason for either of these APIs to care about the character set of the input values (though individual modules may have reasons to care).
Can't follow you: if some modules do care, the core PAM/NSS must handle the character sets somehow in order to pass strings right, or not?
Example: nss_ldap and pam_ldap talk to servers which specify UTF-8 as the wire encoding. However, this doesn't require either PAM or NSS to care about encodings: we should either agree that all input strings are UTF-8, or that they're in the encoding of the current locale. I happen to favor using UTF-8 for everything, but it doesn't matter a whole lot: there just needs to be a convention. And if we say "strings use the current locale encoding", then anyone who needs to handle large chunks of Unicode from within Wine needs to be using a UTF-8 locale. This seems like a reasonable compromise to me, really: for Unix apps, it will definitely be the case that user input will be in the encoding of the current locale, and if they need more flexibility than that from Wine, all they need to do is change to a locale that supports what they want to do!
Most other PAM and NSS backends are not charset-aware, so for the most part having charset-aware APIs around them doesn't help you any, because you don't know what you have to change the encoding to for it to be useful! This is the case with NIS, password files, Kerberos (unfortunately!), and pretty much everything else except for LDAP and winbind.
And if you mean UCS2-capable, don't expect for that to happen, either: Unix already has a standard Unicode encoding, and it supports all 32-bits of the codepoint space and does so without breaking traditional C string handling, thankyouverymuch.
If these tools properly supported ISO10646, UTF-8, or equivalent, we'd be set.
Since UTF-8 behaves exactly like any 8-bit locale wrt string handling, it's a complete pass-through for almost anything related to authentication. Again, the only things I know of that will need to deal with encodings at all are LDAP backends, winbind, and Wine itself.
Regardless, I agree that PAM and NSS are probably not what you're looking for. What you're probably *really* looking for is a complete DCE/RPC implementation for Unix, of the sort that dcerpc.org aims to provide. I know from talking with some of the Samba-TNG developers that they, at least, are eager for Wine to work with them to standardize on a common set of RPC implementations. :)
What I am _not_ looking for is Wine working around Unix security mechanisms. Even if Wine had a well-designed, well-tested internal security mechanism (which isn't the case AFAICT) this would mean running Wine on any Unix system would be dangerous. Thus proper use of PAM is IMO mandatory. If we loose out on character set support, bad luck for some environments, but no reason to have an independent security authority on a Unix system.
I happen to think that the suggestion tendered in this thread to give Wine suid capabilities is a much more serious case of "working around Unix security mechanisms" than not requiring Windows apps to use Unix authentication APIs would be. Giving Wine itself the capabilities to switch security contexts is equivalent to having an suid jvm: suid binaries should be small, carefully audited pieces of code, and I just don't see that as being realistic in the case of something as complex as a virtual machine. The more a user can ask an suid application to do for them, the greater the danger of a compromise -- and there are many things you can ask Wine to do for you! If Windows applications really need to be able to change security contexts, they should gain this privilege the same way as everything else: either you start the application as root, or you set the Windows binary itself suid root and you make sure the Linux kernel has the necessary hooks to confirm this when the application starts (binfmt_misc support should already imply this).
Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them.
Not what winbindd is meant for, really.
winbind makes a small subset of Windows RPC calls available to Unix applications. Windows applications running under Wine will make sense (and perhaps need) a larger subset of these calls. An interface like winbind's, using Samba libs internally, would be by far the easiest way for Wine to to offer this service to applications.
Certainly winbind wasn't written with Wine in mind. The question is not what winbind was meant for, but whether its authors would agree to widen its scope. If not, wine must go a different route, e.g. by writing a compatible replacement (aka "winebind" :-).
As noted in the thread on samba-technical, what you're really asking for is access to arbitrary DCE/RPC services; and you need to communicate with those services across pipes or sockets, because of the GPL. Cramming all of that into winbind really mucks up what winbind was written for in the first place. There is already a project underway at dcerpc.org that hopes to achieve what you're asking for. Samba's first and foremost goal is to provide file sharing and printer services, and everything else necessarily takes a back seat to that. I'm told Samba is moving away from its current monolithic architecture, but I expect it will be quite a while yet before this bears fruit. In contrast, the dcerpc.org developers have been hard at work for a couple of years now implementing stand-alone daemons for many of the RPC services Wine would use -- lsarpc, winreg, and spoolss among them.
Steve Langasek postmodern programmer
Am Don, 2002-09-26 um 00.01 schrieb Steve Langasek:
And if we say "strings use the current locale encoding", then anyone who needs to handle large chunks of Unicode from within Wine needs to be using a UTF-8 locale.
Forgive me, I'm pretty dumb when it comes to character sets. If I understand you right, UTF-8 will pass intact through a non-character-set-aware communication layer (i.e. one that handles strings with standard C library functions such as strlen()).
I happen to think that the suggestion tendered in this thread to give Wine suid capabilities is a much more serious case of "working around Unix security mechanisms" than not requiring Windows apps to use Unix authentication APIs would be.
I agree. Wine itself shouln't be able to change uid. Even if Wine implemented a perfect authorization mechanism for the respective wine "system calls", someone could build a winelib DLL with direct setuid() calls that would succeed if the Wine process loading the DLL had the SUID capability. Sounds evil.
If Windows applications really need to be able to change security contexts, they should gain this privilege the same way as everything else: either you start the application as root, or you
That's not much better than having Wine suid root in the first place :)
set the Windows binary itself suid root and you make sure the Linux kernel has the necessary hooks to confirm this when the application starts (binfmt_misc support should already imply this).
Most processes will be started from within wine by opening the file and jumping to its entry point - suid bits on the files won't help a lot in that context, unless wine is able to change personality.
Imagine some server that requires a user to log in and carries out something on that user's behalf, with his credentials.
Honestly, I have no idea how something like that could be achieved without severely compromising system security. Perhaps it would be possible to design a small, easy-to-audit helper tool that would be started by wine in such a case to check the credentials again and start a new wine process; something in the spirit of sudo.
In any case, IMO wine should rather not support this at all than compromise the host system.
In contrast, the dcerpc.org developers have been hard at work for a couple of years now implementing stand-alone daemons for many of the RPC services Wine would use -- lsarpc, winreg, and spoolss among them.
Thanks, I'll have a look into that.
Martin
-
Andriy Palamarchuk -
Martin Wilck -
Steve Langasek