diff options
Diffstat (limited to 'open_issues/dbus.mdwn')
| -rw-r--r-- | open_issues/dbus.mdwn | 249 |
1 files changed, 248 insertions, 1 deletions
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn index a41515a1..b3bebf48 100644 --- a/open_issues/dbus.mdwn +++ b/open_issues/dbus.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -253,3 +253,250 @@ See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*. to know how to find this sendmsg.c file? <pinotree> (it's in glibc, but otherwise the remark is valid) <pinotree> s/otherwise/anyway/ + + +# Emails + +# IRC, freenode, #hurd, 2013-10-16 + + <braunr> gnu_srs: how could you fail to understand credentials need to be + checked ? + <gnu_srs> braunr: If data is sent via sendmsg, no problem, right? + <braunr> gnu_srs: that's irrelevant + <gnu_srs> It's just to move the check to the receive side. + <braunr> and that is the whole problem + <braunr> it's not "just" doing it + <braunr> first, do you know what the receive side is ? + <braunr> do you know what it can be ? + <braunr> do you know where the corresponding source code is to be found ? + <gnu_srs> please, describe a scenario where receiving faulty ancillary data + could be a problem instead + <braunr> dbus + <braunr> a user starting privileged stuff although he's not part of a + privileged group of users for example + <braunr> gnome, kde and others use dbus to pass user ids around + <braunr> if you can't rely on these ids being correct, you can compromise + the whole system + <braunr> because dbus runs as root and can give root privileges + <braunr> or maybe not root, i don't remember but a system user probably + <pinotree> "messagebus" + <gnu_srs> k! + <braunr> see http://www.gnu.org/software/hurd/open_issues/dbus.html + <braunr> IRC, freenode, #hurd, 2013-07-17 + <braunr> <teythoon> and the proper fix is to patch pflocal to query the + auth server and add the credentials? + <braunr> <pinotree> possibly + <braunr> <teythoon> that doesn't sound to bad, did you give it a try? + + +# IRC, freenode, #hurd, 2013-10-22 + + <gnu_srs> I think I have a solution on the receive side for SCM_CREDS :) + + <gnu_srs> A question related to SCM_CREDS: dbus use a zero data byte to get + credentials sent. + <gnu_srs> however, kfreebsd does not care which data (and credentials) is + sent, they report the credentials anyway + <gnu_srs> should the hurd implementation do the same as kfreebsd? + <youpi> gnu_srs: I'm not sure to understand: what happens on linux then? + <youpi> does it see zero data byte as being bogus, and refuse to send the + creds? + <gnu_srs> linux is also transparent, it sends the credentials independent + of the data (but data has to be non-null) + <youpi> ok + <youpi> anyway, what the sending application writes does not matter indeed + <youpi> so we can just ignore that + <youpi> and have creds sent anyway + <braunr> i think the interface normally requires at least a byte of data + for ancilliary data + <youpi> possibly, yes + <braunr> To pass file descriptors or credentials over a SOCK_STREAM, + you need to send or + <braunr> receive at least one byte of non-ancillary data in + the same sendmsg(2) or + <braunr> recvmsg(2) call. + <braunr> but that may simply be linux specific + <braunr> gnu_srs: how do you plan on implementing right checking ? + <gnu_srs> Yes, data has to be sent, at least one byte, I was asking about + e.g. sending an integer + <braunr> just send a zero + <braunr> well + <braunr> dbus already does that + <braunr> just don't change anything + <braunr> let applications pass the data they want + <braunr> the socket interface already deals with port rights correctly + <braunr> what you need to do is make sure the rights received match the + credentials + <gnu_srs> The question is to special case on a zero byte, and forbid + anything else, or allow any data. + <braunr> why would you forbid + <braunr> ? + <gnu_srs> linux and kfreebsd does not special case on a received zero byte + <braunr> same question, why would you want to do that ? + <gnu_srs> linux sends credentials data even if no SCM_CREDENTIALS structure + is created, kfreebsd don't + <braunr> i doubt that + <gnu_srs> To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0; + <braunr> bbl + <gnu_srs> see the test code: + http://lists.debian.org/debian-hurd/2013/08/msg00091.html + <braunr> back + <braunr> why would the hurd include groups when sending a zero byte, but + only uid when not ? + <gnu_srs> ? + <braunr> 1) Sent credentials are correct: + <braunr> no flags: Hurd: OK, only sent ids + <braunr> -z Hurd: OK, sent IDs + groups + <braunr> and how can it send more than one uid and gid ? + <braunr> "sent credentials are not honoured, received ones are created" + <gnu_srs> Sorry, the implementation is changed by now. And I don't special + case on a zero byte. + <braunr> what does this mean ? + <braunr> then why give me that link ? + <gnu_srs> The code still applies for Linux and kFreeBSD. + <gnu_srs> It means that whatever you send, the kernel emits does not read + that data: see + <gnu_srs> socket.h: before struct cmsgcred: the sender's structure is + ignored ... + <braunr> do you mean receiving on a socket can succeed with gaining + credentials, although the sender sent wrong ones ? + <gnu_srs> Looks like it. I don't have a kfreebsd image available right now. + <gnu_srs> linux returns EPERM + <braunr> anyway + <braunr> how do you plan to implement credential checking ? + <gnu_srs> I'll mail patches RSN + + +# IRC, freenode, #hurd, 2013-11-03 + + <gnu_srs> Finally, SCM_CREDS (IDs) works:) I was on the right track all the + time, it was just a small misunderstanding. + <gnu_srs> remains to solve the PID check + <youpi> gnu_srs: it should be a matter of adding + proc_user/server_authenticate + <gnu_srs> there are no proc_user/server_authenticate RPCs? + <gnu_srs> do you mean adding them to process.defs (and implement them)? + <youpi> gnu_srs: I mean that, yes + + +# IRC, freenode, #hurd, 2013-11-13 + + <gnu_srs> BTW: I have to modify the SCM_RIGHTS patch to work together with + SCM_CREDS, OK? + <youpi> probably + <youpi> depends on what you change of course + + +# IRC, freenode, #hurd, 2013-11-15 + + <gnu_srs> Hi, any ideas where this originates, gdb? warning: Error setting + exception port for process 9070: (ipc/send) invalid destination port + <braunr> gnu_srs: what's process 9070 ? + <gnu_srs> braunr: It's a test program for sending credentials over a + socket. Have to create a reproducible case, it's intermittent. + <gnu_srs> The error happens when running through gdb and the sending + program is chrooted: + <gnu_srs> -rwsr-sr-x 1 root root 21156 Nov 15 15:12 + scm_rights+creds_send.chroot + + +## IRC, freenode, #hurd, 2013-11-16 + + <gnu_srs> Hi, I have a problem debugging a suid program, see + http://paste.debian.net/66171/ + <gnu_srs> I think this reveals a gnumach/hurd bug, it makes things behave + strangely for other programs. + <gnu_srs> How to get further on with this? + <gnu_srs> Or can't I debug a suid program as non-root? + <pochu> gnu_srs: if gdb doesn't work for setuid programs on hurd, I suppose + you could chmod -s the binary you're trying to debug, login as root and + run it under gdb + <gnu_srs> pochu: When logged in as root the program works, independent of + the s flag setting. + <pochu> right, probably the setuid has no effect in that case because your + effective uid is already fine + <pochu> so you don't hit the gdb bug in that case + <pochu> (just guessing) + <gnu_srs> It doesn't work in Linux either, so it might be futile. + <gnu_srs> trying + <pochu> hmm that may be the expected behaviour. after all, gdb needs to be + priviledged to debug priviledged processes + <gnu_srs> Problem is that it was just the suid properties I wanted to + test:( + <braunr> gnu_srs: imagine if you could just alter the code or data of any + suid program just because you're debugging it + + +## IRC, freenode, #hurd, 2013-11-18 + + <gnu_srs> Hi, is the code path different for a suid program compared to run + as root? + <gnu_srs> Combined with LD_PRELOAD? + <teythoon> gnu_srs: afaik LD_PRELOAD is ignored by suid programs for + obvious security reasons + <gnu_srs> aha, thanks:-/ + <braunr> gnu_srs: what's your problem with suid ? + <gnu_srs> I made changes to libc and tried them out with + LD_PRELOAD=... test_progam. It worked as any user (including root), + <gnu_srs> but not with suid settings. Justus explained why not. + <braunr> well i did too + <braunr> but is that all ? + <braunr> i mean, why did you test with suid programs in the first place ? + <gnu_srs> to get different euid and egid numbers + + <gnu_srs> hi, anybody seen this with eglibc-2.17-96: locale: relocation + error: locale: symbol errno, + <gnu_srs> version GLIBC_PRIVATE not defined in file libc.so.0.3 with link + time reference + <teythoon> yes, I have + <teythoon> but afaics nothing did break, so I ignored it + + +## IRC, freenode, #hurd, 2013-11-23 + + <gnu_srs> Finally 8-) + <gnu_srs> Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported + jointly. RFCs will be sent soon. + + +## IRC, freenode, #hurd, 2013-12-05 + + <gnu_srs> I have a problem with the SCM_CREDS patch and dbus. gamin and my + test code runs fine. + <gnu_srs> the problem with the dbus code is that it won't work well with + <gnu_srs> auth_user_authenticate in sendmsg and auth_server_authenticate in + recvmsg. + <gnu_srs> Should I try to modify the dbus code to make it work? + <youpi> unless you manage to prove that dbus is not following the posix + standard, there is no reason why you should have to modify dbus + <gnu_srs> I think the implementation is correct, + <gnu_srs> but auth_user_authenticate hangs sendmsg until + auth_seerver_authenticate is executed in recvmsg. + <gnu_srs> and dbus is not doing that, so it hangs in sendmsg writing a + credentials byte. + <gnu_srs> well the credentials byte is definitely non-posix. + <gnu_srs> I found a bug related to the HURD_DPORT_USE macro too:-( + <youpi> ah, yes, auth_user_authenticate might be synchronous indeed, let me + think about it + <gnu_srs> Nevertheless, I think it's time to publish the code so it can be + commented on:-D + <youpi> sure + <youpi> publish early, publish often + + +# IRC, freenode, #hurd, 2014-01-17 + + <gnu_srs> youpi: as a start all our requested dbus changes are now + committed, and in Debian unstable + <youpi> good :) + + +# IRC, freenode, #hurd, 2014-01-30 + + <pochu> dbus has some known problems + <pere> known fixes too? + <pochu> http://www.gnu.org/software/hurd/open_issues/dbus.html + <gnu_srs> pochu: Maybe that page should be updated: + http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html + <youpi> gnu_srs: well, maybe you can do it : + <youpi> ) |