[EMAIL PROTECTED] writes:
> I straced sudo and found this in the output:
>
> open("/proc/fs/openafs/afs_ioctl", O_RDWR) = -1 ENOENT (No such file or
> directory)
> open("/proc/fs/nnpfs/afs_ioctl", O_RDWR) = -1 ENOENT (No such file or
> directory)
>
> I looked in /proc, and found that /proc/fs doesn't exist within the
> vservers. After digging around, I found that I could make
> /proc/fs/openafs/afs_ioctl visible within the vservers with some
> setattr commands on the host system:
>
> # setattr --~hide /proc/fs/
> # setattr --~hide /proc/fs/openafs
> # setattr --~hide /proc/fs/openafs/afs_ioctl
>
> And now I get a PAG with a token when logging into a vserver on that
> host. Problem solved?
Ah, yes, that would do it.
> Can you think of any reason why it would be a problem for the host's
> /proc/fs/openafs/afs_ioctl to be available to all of the vservers? Any
> security implications? Could one vserver do something to the host or to
> another vserver by having access to this?
If I remember how vserver works properly (one kernel running for the whole
system), it would allow root in any vserver to change the AFS cache
parameters for the whole system and to get trace information about what
the AFS client is doing. I can't think of a way that this could be used
to get other people's credentials, but you can definitely get information
about the system and change things (like cell VLDB servers). Basically,
this is the interface used by all AFS command-line clients, so it opens up
all the things that you can do with the fs and cmdebug commands and
friends to root in the vserver.
AFS doesn't really have a split permission model that fits the vserver
model (as I understand it; I've not personally used one). It figures that
if you're root, you're root.
> If so, could there be some other way for the pam module to detect the
> presence of afs, or some way to override what the pam module currently
> does to detect afs?
No, what the PAM module is doing to detect whether AFS is available is
exactly the same thing that it does to create a PAG or store a token.
It's failing precisely because it can't do anything. Without that
interface, it can't create a PAG.
klog and pagsh are falling back on making system calls, which I believe
indicates that you must be running an old kernel since that's no longer
possible with current kernels. That's why libpam-openafs-session doesn't
bother to implement the kernel system call approach (and neither does its
successor); it usually doesn't work on Linux platforms. However, if klog
and pagsh can make system calls, you aren't adding any new vulnerabilities
by exposing the /proc interface. The functionality exposed by the /proc
interface is exactly equivalent to what's possible via system calls; it's
just used by preference because Linux kernels no longer let modules fiddle
with the system call table.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
