On Tue, May 14, 2002 at 11:23:15AM -0400, Sam Hartman wrote:
> But wait, there's pam_setcred, that evil hack that sort of snuck in
> for some reason--perhaps because someone had heard of Kerberos and
> didn't quite understand it, or perhaps because someone wanted to write
> pam_group. Now, we have pam_group (I think that's the right module),
> which will add you to certain groups under certain conditions;
> pam_krb5, which sets up network credentials, and many other modules.
I think they may also have been thinking of NIS+. Evil hack indeed.
> Long term, I think having PAM evolve to handle credentials
> establishment would be a net good; it would certainly help some of my
> long-term projects and would better mirror some of the better parts of
> the Windows security model. (I don't think emulating Windows for the
> sake of emulating Windows is good, but in this area I think they have
> a better architecture than we currently do.)
Here I must repeat my mantra: it is worth following Windows in this
instance, like so:
- processes should have an array of creds, much like they have array of
open files
- each thread (or cloned process) should have a "current cred_t" which
is used for permissions checking by all system calls / file systems
- creds should be an opaque-ish type like the BSD/Solaris cred_t,
but extensible and with each cred_t containing at most one of each
sub-cred type.
Think of cred types such as:
- POSIX (e.g., UID/GID, with effective and real for compatibility)
- capabilities
- Kerberos (as in a ccache name / open file, but not the actual tickets)
- SIDs (for Windows compatibility and because they are better than UIDs)
- etc...
- this would enable the emulation of the Windows user impersonation
system calls, which are much better and simpler to use that set*id()
- this would allow multi-threaded processes that impersonate client users
- SIDs really are superior to UIDs/GIDs - to begin with SIDs support a
hierarchical namespace, whereas UID/GIDs can only implement a flat
namespace
> Of course when you take things to their logical conclusion, PAM would
> be responsible both for the setuid call *and* initgroups; I think
> doing one without the other would be wrong.
Yes, of course, though setuid() would be replaced with an
assume_given_cred_t()...
> Getting to that ideal world would be very difficult; I think the PAM
> upstream, libc upstream and application writers would all disagree
> with us. We'd also need to think carefully about the API and
> potentially change things and better define things such that PAM could
> actually be responsible for user credential management. But hey if
> anyone ever wants to fight that battle, I'm certainly interested in
> helping.
And I'm suggesting major surgery on the kernel-level process credentials
concept... Eerybody runs away from this.
>
> --Sam
Cheers,
(awaiting flames) Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
