Hello,
Our environment is currently using 2 AD/realms. I am trying to set up
a RHEL3 host to authenticate users from both realms. If the
default_realm in /etc/krb5.conf is set to one realm, the users in the
other realm cannot authenticate and vice versa. So there is no issue on
any
I have lots of uses for PAGs besides tracking krb5 tix. I don't want a
PAG-like item per-such use. I want a daemon (least priv and all that)
that tracks PAG-{whatever} associations.
I'm curious ... why do you want a userspace daemon to be involved? I think
you could simplify things by making a
On Fri, Mar 31, 2006 at 01:27:49PM -0500, Ken Hornstein wrote:
I have lots of uses for PAGs besides tracking krb5 tix. I don't want a
PAG-like item per-such use. I want a daemon (least priv and all that)
that tracks PAG-{whatever} associations.
I'm curious ... why do you want a userspace
First-class multi-application PAGs would not be so cheap in the kernel,
and there would have to be a finite number and registry of applications
to prevent resource consumption attacks. Adding applications to the
registry would be a complication (you don't want to have to reboot for
that)
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all tickets in the kernel? (Presumably
in pageable, accounted memory...).
Well, actually, I'd rather have the whole ticket
While you are thinking about PAGs, how do you handle Solaris zones
with PAGs?
AIX and HPUX had a PAG field in the creds to be used with DFS.
Since DFS come out of Transarc then part of IBM and since DFS was
based on AFS, they may have gotten their kernel people to add the
field so the PAG could
Ken Hornstein wrote:
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all tickets in the kernel? (Presumably
in pageable, accounted memory...).
Well, actually, I'd
On Fri, Mar 31, 2006 at 03:41:13PM -0600, Douglas E. Engert wrote:
While you are thinking about PAGs, how do you handle Solaris zones
with PAGs?
The simple kernel PAG approach is orthogonal to zones: your pag_t's will
be unique to the whole system, zones or not. The filesystem namespace,
and,
On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
Ken Hornstein wrote:
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all
On Fri, Mar 31, 2006 at 04:39:57PM -0500, Ken Hornstein wrote:
Why store tickets in the kernel, what's the point? Presumably you'd not
want anything other than TGTs in the kernel, so where do you cache
service tickets? Or do you want all tickets in the kernel? (Presumably
in pageable,
Which attacks are we talking about? Attacks on the /tmp/krb5cc_uid
scheme? Yes, that's weak. But it is absolutely not the case that all
user-land schemes are inherently subject to that sort of attack; in
fact, modern architectures and operating systems provide lots of
facilities, beginning with
On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
The caches I see are tiny,
Unless the the KDC is Windows, and the tickets have PACs. A tgt is 2000
bytes,
If you're using Kerberos V for authentication in remote administration
protocols and have, say, 30,000 hosts to look after then your ccache
would grow to:
14KB x 30,000 = *huge* (~410MB)
Oh, come on ... this is a strawman argument. You'd have to make some
serious changes to make this work with
Richard,
Thanks for the reply. I'm not sure I know what to look for. It's
strange. Using ssh, if I issue a null password, I get the following
message:
$ ssh [EMAIL PROTECTED]
Password:
Enter Kerberos password for chq-brettm:
Kerberos authentication failed: password
On 2006-03-30 01:21:04 +0200, Quinten [EMAIL PROTECTED] said:
Our environment is currently using 2 AD/realms. I am trying to set up
a RHEL3 host to authenticate users from both realms. If the
default_realm in /etc/krb5.conf is set to one realm, the users in the
other realm cannot
On Fri, Mar 31, 2006 at 05:17:10PM -0500, Ken Hornstein wrote:
Which attacks are we talking about? Attacks on the /tmp/krb5cc_uid
scheme? Yes, that's weak. But it is absolutely not the case that all
user-land schemes are inherently subject to that sort of attack; in
fact, modern
On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 03:44:57 PM -0600 Douglas E. Engert
[EMAIL PROTECTED] wrote:
The caches I see are
On Fri, Mar 31, 2006 at 05:38:30PM -0500, Ken Hornstein wrote:
If you're using Kerberos V for authentication in remote administration
protocols and have, say, 30,000 hosts to look after then your ccache
would grow to:
14KB x 30,000 = *huge* (~410MB)
Oh, come on ... this is a strawman
On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
What other kernel-land applications can you think of or imagine that
fundamentally needs direct multi-application PAG support in the kernel
I agree that you can design a user-land scheme that's a lot better than
a simple file, but there are enough tools available for grovelling through
a user-level daemon's memory that I would prefer to have something better.
Again, it's not 100%, but it's all a matter of degree.
One tool name:
On Fri, Mar 31, 2006 at 06:29:57PM -0500, Ken Hornstein wrote:
I agree that you can design a user-land scheme that's a lot better than
a simple file, but there are enough tools available for grovelling through
a user-level daemon's memory that I would prefer to have something better.
On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
What other kernel-land applications can you think
On Fri, Mar 31, 2006 at 07:07:43PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
- Encrypted (local) filesystems
Orthogonal to PAGs. The kernel needs to know keys for encrypting
objects/filesystems, but access
On Friday, March 31, 2006 06:27:22 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Fri, Mar 31, 2006 at 07:07:43PM -0500, Jeffrey Hutzelman wrote:
On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
- Encrypted (local) filesystems
Orthogonal to
Really, I think the introduction of a new process to keep track of
PAG-appid mappings is just silly. The number of PAG application types in
the system is likely to be quite small, and the mappings themselves are
small as well. Why not just store them in the PAG structure and be done
with it?
The encrypted filesystem argument holds no water, IMO. Ken H. agrees
that all other kernel-side applications can upcall to do PAG-stuff
resolution if need be. What's left?
Ken is wrong.
Careful, now :-) When I was agreeing with Nico, I was specifically
talking about storing Kerberos
26 matches
Mail list logo
