[OpenAFS-devel] Re: Lockdown for VL and VOL RPC interfaces for non-authenticated user

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

--------------ms060604090206080800070008
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3/17/2014 10:13 AM, Gergely Risko wrote:
> On Sat, 15 Mar 2014 23:01:15 -0400, Jeffrey Altman <jaltman@your-file-s=
ystem.com> writes:
>=20
>> Gergely,
>>
>> I'm going to prune the majority of the content because I would like to=

>> focus on the threats you wish to protect against.
>=20
> Thank you for the very detailed response, I'll try to address the issue=
s
> raised in your response.
>=20
>> You have proposed a mechanism for locking down some of the RPCs on the=

>> VOL and VL services based upon:
>>   system:anyuser (the current behavior)
>>   system:authuser
>>   system:administrator
>>
>> I believe that such broad controls on the RPCs that are not used by th=
e
>> cache managers are reasonable.  Doing so will not violate the agreemen=
t
>> with IBM on the use of the AFS protocol.  However, I'm not sure that
>> doing so will address your specific threats.
>>
>> I also believe there needs to be an additional level to permit
>> system:authuser + authenticated foreign users.
>=20
> Forgive my unfamiliarity with foreign users in AFS, but is there alread=
y
> some mechanism to have "friendly zones", because just allowing anyone
> with an AFS ticket to any zone doesn't seem to be fruitful (it's easy t=
o
> install a fake zone for yourself).

I'm not sure what you mean by "zone" although I believe you mean the
same thing as "cell" which is the AFS terminology.

In AFS a cell is an administrative domain containing a collection of:

 * servers
 * volumes
 * protection users / ids
 * protection groups / ids

Each cell can have one or more Kerberos realms as a local authentication
source.  When more than one realm is *local* it is
required that the non-realm components of the Kerberos principal names
when present in multiple realms must all refer to the same entity.

When Kerberos realms are configured for cross-realm authentication it is
possible for AFS cells to leverage the cross-realm authentication to
permit foreign (or remote or cross-realm) users to be assigned an AFS ID
in the cell.  This foreign principal name to AFS ID mapping is automated
by aklog unless -noprdb is used.

Foreign user registration is only permitted if a system:authuser@realm
group is defined in the the protection database.

Arbitrary users cannot obtain an AFS token for a cell.  Even when they
do, only principal names that are assigned AFS IDs in the protection
database are not anonymous.

> Also, I agree with the comments in this thread to reuse the already
> existing terminology of AFS, so I will call my options:
>   - anyuser (default)
>   - authuser
>   - administrator
>   - ??? (how should we call your authuser + foreign user class?)

authuser+foreign

> What should be the sysadm interface for this feature?  A vlserver confi=
g
> that can be added in /etc/openafs/BosConfig?  Or a new file in
> /etc/openafs/server?  Or a dynamic setting that can be changed and
> queried through a vos RPC?

Configuration options that are set as part of the BosConfig.

>> There are a variety of methods by which spammers do this today:
>>
>> 1. They scan the contents of the "home", "usr", "user", etc. tree in t=
he
>>    cell's file system name space.   The list of mount points is more
>>    often then not system:anyuser "l" or at best system:authuser "l"
>>    in order to permit users to see each others home directories and
>>    because machines they login into must be able able to access the
>>    home directories before the user's authentication tokens have been
>>    obtained.
>=20
> In my setting I don't plan to give system:anyuser access to the user
> store.  If users want to publish data in AFS, we will have separate
> volumes for that which will not contain their username (nor in the
> volume name, nor in the path that the volume is mounted on).
>=20
> But yes, in already existing installations, where public space is
> e.g. provided at locations like /afs/elte.hu/user/e/errge/public my fix=

> is kind of pointless, because it's obvious that there is an errge user.=


Requiring system:authuser for home directory access is fine provided
that machines do not require anonymous access to the home directories
for access to .k5login files or the .ssh directory or other data that is
used to decide when a user is permitted to login.

Windows systems for example require the ability to read the profile
directory before authentication has been performed.

>> 2. "vos listvldb" can be used to obtain the list of all volumes.  The
>>    user names can often be extracted from the volume names.
>=20
> Yes, I want to fix this one.
>=20
>> 3. "vos listaddr" to obtain the list of all file servers combined with=

>>    "vos listvol" can be used to obtain a list of all volume names.
>=20
> And this one too.
>=20
>> There is little benefit to locking down the vlserver and the volserver=

>> if the file system can be searched.
>=20
> But it can't be in a lot of cases.  Also, I don't really want to defend=

> against system:authuser.  Because it's very hard to do that.  They can
> use unix "last" or "w" command on shell servers to mine email
> addresses in a standard university setting.  On the other hand doing so=

> they risk being punished for actions like this.  At the same time you
> can't punish random chinese IP addresses sending vos listvol RPCs to
> your servers.

The chances of being caught in a university environment are very slim.
There have been a number of articles published in the last two years
regarding e-mail lists being sold to spammers from insiders.

I agree that reducing access to anonymous users and blocking end users
from modifying ACLs to restore anyuser access is critical.

>>>   - spammers can confirm based on the stats the list of users that ar=
e
>>>     actually active on a computer system,
>>
>> The cache manager debug interface (cmdebug) is implemented by all
>> existing AFS cache managers.  This interface can be used to obtain the=

>> list of FIDs in the cache including the active set of callbacks.  The
>> FIDs indicate the cell and the volume by ID.  The ID can be converted =
to
>> a volume name using VL_GetEntryByName*() RPCs that must be open to
>> permit cache managers to lookup the file server/partitions on which a
>> volume is located.
>>
>> The "vos examine" reported statistics are not necessary.   There is no=

>> authentication on the cache manager debugging interface because there =
is
>> no mechanism for keying the service.   The "volume stats" also are not=

>> collected for a specific "computer or device" but for the cell as a wh=
ole.
>=20
> This cache manager information leak is interesting, thanks for pointing=

> it out.  Is this true for local users or also remotely talking to the
> cache manager?  So is the debug interface open for remote connections?
>=20
> I plan to use AFS with client laptops where every laptop has one user
> and don't plan to give shell access to big shared shell servers.  This
> is why my question is relevant.

All AFS and RX debugging and statistics interfaces are wide open to the
world unless the local machine restricts access via firewall rules.

The cache manager and RX debugging / statistics interfaces do not have
any security class so there is no possibility for using authentication
and access controls based upon group memberships.  These interfaces also
do not know about the protection database and adding such a dependency
would be undesirable.

>>>   - from the vol stats people can monitor and figure out if someone i=
s
>>>     at the computer using AFS which can be part of a bigger social
>>>     attack or harrasment scenarios.
>>
>> The volume statistics can indicate which volumes are more actively use=
d.
>=20
> Yes, exactly that was my point to, that's why I'd like to get rid of th=
e
> public availability of those RPCs if not needed by cache managers.

They are not required by cache managers.

> I'd like to elaborate a bit more on this sentence from your email:
>> There is little benefit to locking down the vlserver and the volserver=

>> if the file system can be searched.
>=20
> This is true when we're designing a new security system and I of course=

> hold myself to this principle when I design new systems through my
> everyday work.  This case is on the other hand is a bit different.  If
> we don't start to take care of these issues at least when it's easy,
> then we will always be adding new (or leaving open old) holes with the
> reasoning seen here:
>=20
>   http://lists.openafs.org/pipermail/openafs-info/2012-July/038333.html=

>=20
>   "I think it is fine to skip access control checks on this call
>   entirely.  As you point out, the information available via this RPC i=
s
>   also available to unauthenticated clients via the volserver."

You are misinterpreting the issue.  That e-mail is discussing data which
is required to be available to the cache manager under the same criteria
as the ability to list the root of a volume but was not.

The Unix AFS cache manager does not expose AFS volumes as individual
devices.  The Windows cache manager does.  As such it needs to be able
to determine the volume properties at the time the device is
constructed.  We relaxed the authentication check because if the root of
the volume can be accessed anonymously (and all volume root directories
can be queried for status info anonymously) then the volume properties
must also be.

> Security is not black and white, if we fix one leak then we're a little=

> bit better already, I think.  Of course, it's not optimal but we should=

> start somewhere.
>=20
> If you don't think that I'm really going in a bad direction with this
> proposal then I'd appreciate your help in designing and implementing
> what is reasonable now and maybe fixing more later.

I believe that what you are implementing is a reasonable step.  I have
already provided advice and will continue to do so.

The point of my e-mail was to ensure that you understood the specific
threats that you were attempting to protect against.

Jeffrey Altman



--------------ms060604090206080800070008
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC
BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0
aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx
MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh
dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn
/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb
jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR
I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk
VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh
xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI
KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t
MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG
AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw
Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx
GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE
Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT
MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD
BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP
wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM
YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi
Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t
lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ
3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhB4
sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE
ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv
cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa
Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx
MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u
Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf
MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y
cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSrqYUguvbguthxGNq
M15noPYGLMnpjRKT2VS88MxNAZ7RaplB8Azrk8vOH+q+IWnXCrap+BevY27PZW6UgNAPcETG
FTi/qdYAukHwnCV7fvjXXJEOw3jg+eK/06bhr0uThvmrjT+jWHlpzK3mSDPtEBSkgXDbLkL/
LQfYvay0Ia7n65l5Ry4zHlrg6uJ+UqvWJZwXazXjo2H4EksGCM4nrKHTeVoj5oSquvqs3tSf
BytXLGVqSOHqjXb+lri1gtlovX7AjMT2gdONRrjR3wun6tjHvoqjUNZ2mUs0XXh0vI0GyTKd
taz26xY+iKboxFO2atDbb1Gm8KdUXqO/UivlAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA
MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD
VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m
aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr
BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp
c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl
MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO
b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3
b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE
JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br
aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv
TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW
Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu
c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF
MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAEUyacJvoRfQdglYgnUwaTMsRRg0YeAljbnb8M5E
vBSo3u/LhvbXtvu+9uE8R6UOE4GvKH382I27vjuM28oHqfii04URAB1icmA8b7rxYQo9Ob2I
/NkkQRBwbA3HGLWXFjupODWbP5WylyySAAI7HxG2xbE4X+8+hMJVOKfxJb6J0SUOBlnmMkmg
nAxgOM4venSmli6U3o0nADHNLZEJjqym2QstkeYPhDZ6sSO3t/yv+JyYbfb01hiOdhGsDBif
oPTqcWRvA+lqbWMHJG3p9uL/kI4jbLj9/ZkMfdRDHpQNVAuGxxyj7b1pxM0jBuTP0Jmrcz3U
wUwT5kjCCDt2gGAxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5
bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w
HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz
IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEHiwwaDblI88SsZkARSRB5MwCQYF
Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTQwMzE4MTQzMDIwWjAjBgkqhkiG9w0BCQQxFgQUuEu2RnGi1XjtPZFRRXHcf8HFOqMwbAYJ
KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB
zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg
Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp
dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQeLDBoNuUjzxKxmQBFJEHkzCBzgYLKoZIhvcN
AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh
dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhB4sMGg25SPPErGZAEUkQeTMA0GCSqGSIb3DQEBAQUABIIB
AMUn1e8l9wvZnTMKmBKCRfNvjIRkABs0WqkkzqGcQNdsN/5dq4yQWMoo8orT1YdWiA+Yx/d9
hcSi71PhXPfJgBwV2AUIoHd+P+slzOqz9ppmiRcfM0jrcS/ITtxrWz0oFcl8syVrZxI27bGv
eLdWHMd7VHGkm8LWjnfZ6NJ6043UuPhcuzWSsOU9zEPzsbB08VDKjlC5FHfyx67vozjkNDwe
51VznrlUs7/sv0yS+bF4amDrNVoaX9N947BQDrlhvFtHcPsQvAvZ8zyfx02mCcncgMi2AgAb
Vexg7R5CQu4LFar8dh38LS/8vG9uQ1zYyBnk5WidKQNBvoSnvbolIIoAAAAAAAA=
--------------ms060604090206080800070008--