[Standards] Veto on "Privileged Entity"

Goffi goffi at goffi.org
Thu Dec 18 09:06:09 UTC 2014


G'day,

I have started to study ABAC model, starting with 
http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf 
and I understand better the point of view of Dave, actually I have to 
admit that he is right.

After a discussion yesterday on XSF MUC room, I'll go in the following 
direction:

	- I'll restrict privileged entity to only cover the basic needs we 
have, and probably get rid of client mode and genericity

	- I'll start to work on a ABAC system, even if I can see it taking 
time: I really want to see a modern access control system implemented in 
XMPP, and keep it as simple (and implementable) as possible

	- once everybody agree on an ABAC system, we can re-implement a generic 
system to allow external entities to access some of server privileges

Cheers
Goffi

On 17/12/2014 19:01, Goffi wrote:
> On 17/12/2014 18:06, Dave Cridland wrote:
>> OK, I entirely forgot about that. And in fairness, I think Section 6 is
>> reasonable; I think Sections 4 and 5 are the problem.
>
> Ok, it become more precise, I'll work on it
>
>
>> This document is not about building an external PEP service; this
>> document - or at least sections 4/5 of it - is about access control.
>
> right
>
>
>> In this case, as I wrote, every PEP node already has an access-model,
>> and applying a different access model based service-wide around the iq
>> type is clearly both duplicating the access control of PEP, and making
>> it worse, and failing to interact properly.
>
> PEP node is a restricting access model, not something used to give more
> access (or privileged as called in the protoXEP), it is definitely not
> the same thing as PEP access control.
>
>
>> Well, that's sort of the problem - the protocols are already defined on
>> a per-extension basis, and you've applied a generic solution across the
>> top. The two just don't fit.
>
> What I mean is if you want to give access to a feature, in XMPP terms
> it's a XEP (and an associated namespace). As you mentioned in a former
> email, XEP have not a consistent model once in the <query> par of <iq>
> stanza. So how can you give an generic attribute based access control,
> if XEP are organised in all different ways ? You can explicitly mention
> XEP by XEP how to do, but that's not generic anymore, and need to be
> updated when new XEPs appear.
>
>
>> I really think it's worth addressing just the immediate requirements to
>> begin with.
>
> The whole XEP address the immediate requirement, except maybe the
> "client mode" part which is a "bonus".
>
>
>> Like the roster access-model already in PubSub? (I'm pretty sure M-Link
>> does this already for PEP nodes).
>
> Exactly like the roster access-model already in PubSub which is
> implemented nowhere (or at least, in none of the servers I have tested:
> Prosody, Metronome, OpenFire, Ejabberd, which is already a good set),
> except in our PubSub component.
>
> But in Berlin summit I talked about this with Ralph Meijer, and it seems
> that in fact I misunderstood and the "roster" in question in the PubSub
> roster, not publisher's roster like I thought (and I need access based
> on publisher's roster). So it's a model which doesn't exists yet, and
> would be sort of "publisher-roster access-model". That means that before
> having a valid and standard way of doing this, we need a new XEP,
> discussions, etc. And before having this implemented in most of servers
> we can wait... well... ages.
>
>
>> A client *can* manage its own PEP service, can't it?
>
> No it can't, it can only have the PEP service implemented in its server
>
>
>> This protocol would
>> be enabling it to manage someone else's, surely?
>
> No it wouldn't, access is restricted to the client which accepted the
> privileged (see section 5.1 of the protoXEP)
>
>
>> Moreover, if you want
>> to run your own PEP service as a client, you only need the other
>> protoXEP, not this one.
>
> No, the "Namespace delegation" is not sufficient, as a PEP service need
> to send <message> stanza and access <presence> informations, which are
> addressed by the "privileged entity" XEP in section 6. And that also
> means access to roster, also addressed by "privileged entity".
>
>
>> I pointed out the problem with MAM, for example. I have no idea what
>> else is there, but there are problems with PEP as above (and Pubsub and
>> MUC in the same way), and MAM. I wondered about Search, and anything
>> involving ad-hoc is clearly a bit weird.
>
> You pointed out that there is no granularity, but that's not a security
> issue (if you give access to MAM to a component, expect it to do things
> with MAM).
>
>
>> You're asking server administrators to understand the protocol-level
>> issues?
>
> No, I'm asking administrators to understand what they put in
> configuration, and which permissions they allow in a *whitelist* (as
> recommended in section 11): allowing privileged on roster is something
> acceptable, allowing privilege on "http://jabber.org/protocol/xhtml-im"
> make no sens, you don't need to understand the protocol level to
> understand that. In addition, server can have they own hard coded list
> of acceptable namespaces.
>
>
>> But anyway, the problems basically all derive from this being generic.
>
> Yes, the goal is to avoid to be stucked on server implementation for any
> past present or future XEP.
>
>
>> You know you could just write a server? You needn't bother with S2S; you
>> can just run yours as a component into another one. PEP/Pubsub-onna-jid
>> is *way* harder to do than the rest of C2S, and I suspect it's actually
>> easier than doing all this proxying.
>
> You mean having a server as a component ? Something like
> myextraserver.myactualserver.tld ? Above the complexity of the thing, it
> will just not work for PEP, the myactualserver implementation will
> manage all PEP requests, and anyway myextraserver couldn't send
> notification in the name of the client entity. Maybe I misunderstood
> what you suggest, but I'm curious to see a working solution here.
>
>
>> Basically, unless you really want to do the ocean-boiling exercise of
>> doing this properly - and I really don't dispute that it's hard work -
>> then why not strip this down to just section 6 for now?
>
> I can try to work on it anyway, just let me a couple of days to think
> quietly about this and study a bit more XACML and your concerns, maybe
> we can have a satisfying solution without writing an entire new thing
> (and hopefully without postponing by months or years).
>
>
> Goffi
>




More information about the Standards mailing list