Conversation with #inferno at Fri Mar 13 05:57:14 2009 on powerman-asdf@irc.freenode.net (irc)
(09:20:14) wxcv left the room (quit: Remote closed the connection).
(09:32:48) maht left the room (quit: Read error: 104 (Connection reset by peer)).
(09:32:59) maht [n=maht__@85-189-31-174.proweb.managedbroadband.co.uk] entered the room.
(10:27:06) wxcv [n=soul9@biblibre.pck.nerim.net] entered the room.
(10:40:18) hotaru2k3 [n=hotaru@cpe-24-29-193-226.neo.res.rr.com] entered the room.
(10:47:13) npe [i=npe@naist-wavenet125-199.naist.jp] entered the room.
(11:07:45) npe left the room (quit: ).
(11:25:48) hotaru2k3 left the room (quit: "ChatZilla 0.9.84 [Firefox 3.1b2/20081201080242]").
(11:51:50) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(11:57:20) andguent [n=andre@p4FF67844.dip.t-dialin.net] entered the room.
(11:59:45) wxcv left the room (quit: Remote closed the connection).
(12:02:30) wxcv [n=soul9@biblibre.pck.nerim.net] entered the room.
(14:29:34) underspecified left the room (quit: ).
(14:39:13) tombohannon left the room (quit: ).
(14:47:48) npe [i=npe@naist-wavenet125-199.naist.jp] entered the room.
(15:00:42) wxcv: powerman-asdf: around?
(15:00:56) powerman: wxcv: yep
(15:01:14) wxcv: i'm gonna try your inferno ebuild right away
(15:01:23) wxcv: does it check for gcc-3.4?
(15:01:42) powerman: no. what's with gcc? 
(15:02:12) wxcv: well, you get many trap faults and exits (mostly when mounting fs's) with gcc4
(15:02:16) powerman: I'm using 3.4 (because of hardened), but few days ago I've built inferno using 4.0 on mac os x.
(15:02:17) wxcv: at least last time i checked
(15:02:29) wxcv: ok, i'll see..
(15:18:27) wxcv: powerman-asdf: you could just add the fonts from acme-sac, that worked very well in my PKGBUILD
(15:18:43) wxcv: other than that it looks to be working allright
(15:18:53) wxcv: i'll test more thoroughly later....@work now
(15:19:01) wxcv: kudos, powerman-asdf, great stuff
(15:19:13) powerman: wxcv: there few issues with these fonts
(15:19:31) powerman: have already discussed that with uriel few days ago
(15:20:02) powerman: main issue - non-free fonts hardcoded in many wm/* apps
(15:20:24) powerman: and free fonts doesn't work as drop-in replacement
(15:20:55) powerman: in acme-sac this issue was solved by deleting nearly all wm/* apps from distribution :)
(15:21:13) tombohannon [n=tombohan@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(15:22:47) powerman: doing s/non-free fonts/free fonts/ in all wm/* apps will result in huge patch, hard to support and will require a lot of testing (fonts are different, so after that s/// some bugs may be introduced)
(15:32:30) wxcv: hmmm
(15:32:34) wxcv: it worked very well for me
(15:32:48) wxcv: i dunno what apps contain hardcoded values for fonts though
(15:38:52) underspecified [n=eric@softbank220043052007.bbtec.net] entered the room.
(15:55:36) olegfink left the room (quit: Read error: 60 (Operation timed out)).
(15:58:00) olegfink [n=olegfink@62.141.52.142] entered the room.
(16:13:56) gualteri left the room (quit: "byes").
(16:23:56) aguent [n=andre@p4FF65038.dip.t-dialin.net] entered the room.
(16:28:45) eekee: What should I use to try to find an illegal instruction in emu? gdb or acid or what?
(16:29:19) eekee: Or should I try recompiling with gcc 3, bearing in mind I'd have to build gcc 3 on a slow machine first? :J
(16:32:57) andguent left the room (quit: Read error: 110 (Connection timed out)).
(16:34:48) mjl-: eekee: if emu prints the pc, i would use that to look at the emu binary with a disassembler
(16:35:10) mjl-: is that on 386?
(16:35:14) eekee: no, arm
(16:35:21) eekee: and I don't think it does
(16:36:16) mennis [n=mennis@adsl-81-6-56.asm.bellsouth.net] entered the room.
(16:36:43) eekee: oh it does in dmesg
(16:37:18) mjl-: are you on linux?
(16:37:27) mjl-: this is in emu/Linux/os.c:
(16:37:29) mjl-:  * TO DO:
(16:37:29) mjl-:  * To get pc on trap, use sigaction instead of signal and
(16:37:29) mjl-:  * examine its siginfo structure
(16:38:39) eekee: yeah Linux/arm
(16:39:38) eekee: it reports PC & a couple of other registers via dmesg, curiously. Hmm, I could use gdb to disassemble I guess
(16:42:14) mjl-: that makes most sense
(16:42:34) mjl-: well, it wouldn't help if the illegal instruction was in jit-generated code...
(16:42:53) mjl-: perhaps that is detectable with emu -cX with X>1
(16:44:16) mjl-: hah, i always thought limbo's "type" keyword was a bit useless
(16:44:19) mjl-: now i found a use for it
(16:44:28) mjl-: this gives a copmiler error:
(16:44:32) mjl-: t := ref (int, string);
(16:44:35) mjl-: and this does not:
(16:44:39) mjl-: T: type (int, string);
(16:44:39) mjl-: t := ref T;
(16:44:51) mjl-: and that is exactly what i need
(16:46:41) eekee: ah emu -s also
(16:48:10) powerman: I wonder how people do auth in distributed systems...
(16:48:47) powerman: If there, say, 100 services, on several servers...
(16:49:33) powerman: And these servers available from internet (usual co-lo or dedicated, for example)...
(16:50:57) powerman: Even in case inferno auth used, and there single CA, that mean if hacker own 1 service he will get access to all 100.
(16:51:32) mjl-: yes, but the advantage is that you only have to secure 1 service.  and can manage all your accounts in 1 place.
(16:51:35) mjl-: that is a huge benefit
(16:51:58) powerman: Hardcoding dependencies in services - which of other services allowed to access this one - will be management nightmare.
(16:51:59) mjl-: in my experience, more distributed usually also means more complex
(16:52:06) mjl-: and more complex means less likely to be secure
(16:52:26) eekee: hmm gdb says "no function contains the specified address"
(16:52:28) mjl-: why would you hardcode it?
(16:54:32) powerman: What does mean 'secure 1 service'? You mean CA? No, that's not important. For example, if there some php web interface and inferno service (any one of these 100) on same user account, then hacker can own php, get web shell and access ~/keyring/default of that inferno service. Then use it to access all 100 services.
(16:55:39) powerman: Such thing may also happen without php - for example, if keyring/default become exported by mistake or there will be some security hole in public inferno service etc.
(16:56:11) powerman: Got 1 inferno service - *any* one of 100 - got access to all 100.
(16:56:56) mennis left the room.
(16:56:57) powerman: For example, one of these 100 services will provide access to our internal member database. Some other services will need it. But most other - don't.
(16:57:29) mjl-: i understand your point.
(16:57:59) powerman: If one of small, not important and forgotten services will be owned, it's keyring/default can be used to access all our services - i.e. it will got access to member's database too. :(
(16:58:00) mjl-: ideally, you want each service to have its key.  just for itself.  and let the CA enforce that that key can only access some services.
(16:58:12) mjl-: and then you should be able to configure at the CA which services each key can access.
(16:58:16) mjl-: that sounds ideal to me at least.
(16:58:45) powerman: currently CA doesn't support this feature. it's authorization, while current CA do only authentication.
(16:59:30) anothy_x: unless i'm missing something, CAs can't *ever* do authorization.
(16:59:40) powerman: also, managing authorization for some service on CA doesn't sounds ideal for me, because there may be more than one CA used, and so we'll end managing authorization to single service on several CA
(17:00:23) anothy_x: the CAs will be managed separtately, that is by separate human logical administrative domains?
(17:00:31) mjl-: anothy_x: the plan 9 AS can determine per user (read: service) whether it gives back valid tickets
(17:00:32) anothy_x: so you can't assume "joe" in one is "joe" in the other?
(17:00:54) anothy_x: mjl-: i don't understand.
(17:00:56) powerman: anothy_x: yes, you right. the problem is nobody of standard services (like CA/registry/etc.) do authorization now, but we need this feature
(17:01:16) anothy_x: powerman-asdf: okay, that i understand.
(17:01:47) powerman: so, I just *wonder* how people *DO* distributed systems without any standard way to do authorization.
(17:02:03) powerman: it nobody bother about this sort of security at all?
(17:02:08) powerman: it->or
(17:02:26) anothy_x: it has authorization, it's just not the model you seem to need.
(17:02:51) anothy_x: file system permissions are the primary example, of course.
(17:03:20) powerman: that model doesn't seem something special for me - it's must have if you've *many* small services because unlikely all of them should have same access rights
(17:03:47) powerman: or, if it special for me - maybe I'm doing something wrong?
(17:04:25) mjl-: anothy_x: with plan 9 auth, you authenticate client & server by tickets you get from the AS.  the AS can decide some client & server should not be able to do that, and so can enforce that some user cannot talk to some other user.
(17:04:35) mjl-: if i understnad things correctly that is.
(17:04:58) mennis [n=mennis@adsl-81-6-56.asm.bellsouth.net] entered the room.
(17:05:00) mjl-: i suppose you don't need to connect to an infenro auth server to do authentication.  you can just use the offline key.
(17:07:05) anothy_x: powerman-asdf: no, i think you're right, at least as far as i'm aware. like i said, i think authorization decisions are generally pushed to the file system permission in plan 9 and inferno
(17:07:27) anothy_x: (which would be a lot more powerful if it was the auth server, or something similar, that knew about groups, rather than the file server)
(17:08:29) anothy_x: mjl-: i think what you're describing would work, but it's an awful coarse-grained approach to authorization, by way of overloading authentication (simply refusing to authenticate in some instances)
(17:08:52) mjl-: it's really how the p9 AS works...
(17:08:56) anothy_x: the groups-only-in-the-fs thing is a frequent irritation. i'd love a good solution to that.
(17:09:09) anothy_x: mjl-: but it doesn't do it selectively.
(17:09:27) mjl-: exactly
(17:09:44) mjl-: the target service you authenticate against will accept any valid ticket from the AS
(17:09:45) anothy_x: and it shouldn't, at least i don't think.
(17:10:01) anothy_x: right. the AS is just the *authentication* server.
(17:10:20) mjl-: not really
(17:10:26) anothy_x: it doesn't (and shouldn't) know anything about the service being provided, which is what would be needed to do *authorization* service.
(17:11:22) powerman: anothy_x: I don't get it. With static fs it will work, but file services doesn't provide sensible permissions unless they hardcoded in file service. Also, there no support for user groups in styx afaik... So, to use authorization based on file permissions I still have to hardcode in file service which users have access to it.
(17:11:36) mjl-: anothy_x: there is no reason why the AS cannot do both.
(17:12:04) mjl-: and, there is no other mechanism to do authorization anyway.  a service will accept any valid ticket, regardless of for which user it was signed.
(17:12:38) mjl-: it trusts the AS to have made sure the user was valid.
(17:14:11) mjl-: powerman-asdf: i think you could get what you want if you can put in a inferno auth certificate (created by signer) who should accept the certificate.  and then issue only short-lived certificates, and have clients get new certificates when they want to do auth.
(17:14:14) anothy_x: how can the AS do authorization without knowing about the service being authed?
(17:14:39) anothy_x: the existing mechanism for authorization is file system permissions.
(17:16:13) mjl-: anothy_x: you are right about fs permissions doing authorization
(17:16:38) mjl-: i guess what i'm talking about is at a level of no-service or service-with-per-service-authorization-semantics
(17:17:53) anothy_x: valid things to want/have. but they have to be *service* aware, and the auth server isn't, and shouldn't be.
(17:18:09) anothy_x: fossil sorta provides it, for example.
(17:18:45) anothy_x: anyone with an auth ticket (from the right place) can connect, but you've got to have an account with the file server to be able to write.
(17:18:58) anothy_x: (other than world writable, and that can be changed using noworld)
(17:20:46) mjl-: if the service is user-agnostic, why shouldn't the auth server handle the permissions?
(17:20:53) mjl-: sounds like a cheap & easy solution
(17:22:23) anothy_x: because it has to know about the service. what does "permissions" even mean in the context of the service you're talking about?
(17:22:35) anothy_x: in a file server, we know: rwx.
(17:22:35) mjl-: alternatively, you could make certificates from a server contain sub-service access rights (i.e. allow some things in a service, disallow others).
(17:22:40) anothy_x: sorta, mostly.
(17:23:08) anothy_x: mjl-: there's something to be said for that idea, particularly in the inferno world (where we have real certificates)
(17:23:18) mjl-: ok.  so either divide the services in a way such that it can be all-access or no-access.  or put that info in the certificate.  and make the certificate short-lived.
(17:23:36) anothy_x: it'd be interesting to have certificates, issued by an AS for *authentication*, then signed by the services, for *authorization* of different functions.
(17:23:41) mjl-: a ticket from the AS is really a certificate with the semantics of "this is really user X, let him do whatever user X is allowed"
(17:23:54) anothy_x: no, it's just "this is really user X"
(17:24:04) anothy_x: the AS doesn't care what you allow him to do.
(17:24:41) mjl-: it's the same
(17:24:51) mjl-: because "whatever user X is allowed" has no meaning to the AS
(17:25:19) anothy_x: but the AS doesn't say anything about "allowd to do".
(17:25:23) eekee: wow, I actually understood something auth-related :)
(17:25:30) mjl-: and in p9 auth, it is normal/assumed that a user with a valid ticket gets access
(17:25:56) anothy_x: i wish that, in english, authentication and authorization didn't both start with "auth". it causes so much confusion.
(17:25:58) mjl-: i.e. there is no other standard generic auth method of disallowing some users from a service.
(17:27:23) anothy_x: it's true, the assumption (strongly/explicitly in plan9, weakly/implicitly in inferno) is that the service and the AS are run by the same administrative domain.
(17:29:02) mjl-: powerman-asdf: http://code.google.com/p/inferno-spki/
(17:29:07) mjl-: i still have to read more about that
(17:29:21) mjl-: i've become interested in auth/crypto/etc. lately
(17:29:48) mjl-: powerman-asdf: i know from the last iwp9 that charles finished that not too long ago, so it is "fresh"
(17:30:06) anothy_x: is it integrated into mainline?
(17:30:18) mjl-: i don't think so, but am not sure
(17:30:28) eekee: "This software will become part of the main Inferno distribution, but it is convenient to develop it independently in this separate area."
(17:30:48) powerman: I think right solution should be in separating public and internal services. The amount of public services will be small enough, they will carefully check user access & permissions (probably using several CA for different user groups), and existing functionality is enough to secure them. The amount of internal services can be huge, but we can just run all internal services on separate servers, not available from internet, and say 'all internal services and their servers are just ONE huge server with ONE huge service, and if you own part of it - you own it all and that's unavoidable'.
(17:30:50) mjl-: yeah, i recall charles being confident in this auth stuff
(17:39:57) powerman: mjl-: spki isn't authorization, it's authentication
(17:40:51) mjl-: The SPKI specification defines an authorization certificate format, providing for the delineation of privileges, rights or other such attributes (called authorizations) and binding them to a public key.
(17:41:20) powerman: so it doesn't solve main issue: how to manage access right between 100+ services to limit each service access to other services
(17:42:22) powerman: ohh, I probably have to real SPKI spec before talking about it :(
(17:42:39) powerman: s/real/read/
(17:45:09) powerman: anyway. with huge amount of small internal services trying to protect one from another is much like trying to protect processes running on second CPU core if hacker will own process running on first CPU core 
(17:48:06) powerman: also, there performance issues. the smaller services are, the more services we've - the more intercommunication between services will happens. authn, authz and encryption for these intercommunication will cost a lot of CPU and slow down everything
(17:48:35) mjl-: all true
(17:48:43) mjl-: internal/external might just be easiest & secure enough
(17:48:58) mjl-: still, i want to see inferno-spki in action.  perhaps i can play with it this weekend.
(17:49:20) mjl-: it seems spki is in inferno already btw
(17:49:23) mjl-: inferno-os that is
(17:49:31) mjl-: at least, my local inferno copy has the spki files...
(17:50:04) mjl-: hmm, old commit timestamps though
(17:53:45) mjl-: seems to be some old copy...
(18:01:53) wxcv left the room (quit: "left").
(18:04:51) npe left the room (quit: Read error: 60 (Operation timed out)).