[[!meta copyright="Copyright © 2007, 2008, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] UIDs on the Hurd are separate from [[glibc/process]]es. A process has [[capabilities|capability]] designating so-called UID vectors that are implemented by an [[translator/auth]] server. This makes them easily [[virtualizable|virtualization]]. The standard POSIX interfaces to a [[glibc/process]]' UID management are implemented in [[glibc]]. When a process wishes to gain access to a resource provided by a third party (e.g., a file system) and that party wishes to authenticate the client so as to implement some identity-based access control ([[IBAC]]) policy, the latter initiates a three-way authentication handshake. The server and client each then begin an authentication sequence with their respective [[trust]]ed auth servers. If they have a mutally trusted ancestor and an auth server does not abort the transaction, then the client is delivered a new capability naming a newly authenticated session with the server and the server is delivered the client's designated UID vector. For more details, see section 2.3 of the [[critique]]. # Open Issues [[!tag open_issue_hurd]] ## IRC, freenode, #hurd, 2013-09-26 teythoon: hum, i just saw something disturbing teythoon: to isolate the leak, i created my own proc directory and the mtab translators it spawns seem to be owned by root oO braunr: but how is that possible? are you sure? have you checked with 'ids'? no i'm not sure also, ext2fs seems to ignore --writable when started as a passive translator < teythoon> braunr: but how is that possible? messup with passive translators i guess teythoon: actually, it looks like it has effective/available id it has no* this feature doesn't map well in unix braunr: ah yes, htop doesn't handle this well and shows root indeed, our ps shows - as username yes ## IRC, freenode, #hurd, 2013-09-28 mhmm this process has no uid isn't it a security issue that processes can remove their identity ? i really don't like that we allow processes to loose their identity ... braunr: y not? I think that's a killer feature one that is notoriously absent in unices not exactly gaining rights to switch your identity is ok since you have proven that you are allowed to do it now, if you can remove your identity, you can create "ghost" processes processes that can spend their day causing denial of services without the possibility for the administrator to know who is responsible the unix "way" of dealing with DoS is to warn and ban users after they violated the rules we need to have at least that possibility perhaps we need to add an "initial" uid otoh the unix way of dropping privileges is hardly being able to do so at all ;) teythoon: ? on unix, you need privileges to drop your identity :) i understand it involves security risks, but that's understandable the thing is, we actually don't care about dropping privileges we care about gaining them you cannot drop your identity, you can just use another one exactly that's what i want and the way the hurd does it is superior let's keep that processes that should run with least privileges can simply have their own user/group as it's done on unix then how do you obtain such a uid/gid? teythoon: you gain the right, use it to prove who you can be, and ask an identity switch identities would then be managed at server side (in proc for example) I know how it's done on the Hurd, but who creates them for you? the password server well no the password server gives you the right you need to prove who you can be then i'd assume you'd ask the proc server for the switch but who creates the uid for you in the first place, who sets up a passwd entry the administrator ? what bothers me is that it goes directly against the main goal of the hurd indeed but i think it's a better compromise of freedom/order I always thought that the ability to drop the unix-like credentials is really nice ### IRC, freenode, #hurd, 2013-09-29 braunr: dropping privileges doesn't unregister a process from the proc server... so it shouldn't be too hard to find out who is responsible. however, there are more effective ways to create ghost processes -- a special executable skipping the ordinary bootstrap won't be registered with proc at all... however, that would be a non-issue if we had proper resource accounting antrik: I do not believe that this is correct. every mach task will eventually be picked up by the proc server eventually being next time someone fork(2)s or so but if noone uses proc_child to claim the new process ones child, it will not be presented by the proc server as unix process (aiui) teythoon: not sure what you mean by "pick up" of course proc will see the process when listing all tasks on the system; but it will have no additional knowlegde about it (which is the whole purpose of proc) ### IRC, freenode, #hurd, 2013-09-30 antrik: proc should be redesigned to fix these issues in particular, the way that proc lists mach tasks to show them to the rest of the system is something i find deeply disturbing hurd processes should be forced to go through proc braunr: well, if we are talking about fundamentally fixing things, I believe the central proc server is not a good idea in the first place :-) I believe hierarchical management of resource management and information flow -- cf. nghurd and genode -- is a much better approach antrik: i agree with hierarchical management of resources, but i don't see why this prevents a central proc server i.e. one proc server per hurd instance ### IRC, freenode, #hurd, 2013-10-06 braunr: hierarchical management of resources doesn't prevent a central proc server of course; but a central proc server would fit really ill with hierarchical management of permissions... ### IRC, freenode, #hurd, 2013-10-07 antrik: does proc manage permissions ? braunr: well, it manages some permissions... like who is allowed to send signals hm... or perhaps proc is not involved in signal delivery itself? don't remember. but at any rate, proc decides whether it hands out privileged task ports antrik: yes, it decides whether or not a client is allowed to obtain the message port of another task antrik: but i don't see why this is a problem what we have now is one proc server per hurd instance how is that not both central (inside the hurd instance) and hierarchical with regard to resource management ? braunr: we are probably talking past each other all I'm saying is that in an ideal world, there should not be a central server deciding who is allowed to see and/or control other processes antrik: how should it be structured then ? i mean, how would you see it ? child processes should be fully controlled by their parent -- including outside communication (like in genode AIUI) isn't that conflicting with the unix design ? antrik: maybe I'm saying silly stuff since I don't have all the background, but seems problematic to me with SUID/SGID programs antrik: in which a child can be more privilegied than the parent kilobug: that's part of my question too and it's even "worse" with Hurd's addauth in which any process can be given additional rights in runtime, but not its parent braunr: one of the conclusions from ngHurd was that suid as such is problematic. it makes more sense to have privileged services actually run by the privileged user, and only requested by the unprivileged one using RPC admittedly, I'm not sure how this interacts with UNIX compatibility ;-) kilobug: in the genode approach, the parent would control that as well in unix, the idea of parent processes doesn't imply much parents merely exist to reap resources from their children and as templates when forking yeah, but that's one of the major shortcomings of UNIX in my book... sure i'm just thinking out loud if we want to maintain posix compatibility, it seems reasonable to keep it that way despite the shortcomings does that imply a centralized proc server anyway ? I suspect we could similate suid in the hierarchical design, only that the resources would be accounted to the user under whose ID the process runs, rather than to the one who invoked it i also have a hard time seeing what the completely hierarchical model brings compared to what the hurd does (isolating system instances) and I don't think we need a central proc server. it could probably be done similar to the VFS: each process implements the interfaces, passing on to the children as appropriate braunr: it's much easier to isolate parts of the system for security and/or customisation that's actually one of the things discussed in the "critique" IIRC... i'm not sure anyway, processes implementing the interface looks bad to me that's already a problem with the current hurd using normal client processes as servers means we rely on them to behave nicely you have a point there: while untrusted filesystems can be ignored easily, ignoring untrusted proc providers would be problematic... (I don't think it's strictly necessary to know about other user's processes; but we could hardly keep a UNIX feel without it...) other users' i feel the hierarchical model may imply some unnecessary burden capabilities along with resource containers look much more flexible and not less secure children would share the same container as their parent by default, unless they obtain the right to use another or create their own braunr: decoupling control from resource ownership is *always* problematic. that's pretty much the major takeaway from ngHurd discussions (and the major reason why Coyotos was abandoned as a base for ngHurd) if a process runs on your resources, you should have full control over it. anything else faciliates DRM & Co. antrik: i see nonetheless, i don't see the point of that restriction, since the simplest way to avoid drms in the first place is not using them and that restriction makes posix compatibility hard to provide I'm not sure it's really all that hard... IIRC genode is aiming at POSIX compatibility I'm not sure it's any harder than with the current Hurd architecture i didn't see anything like that they provide posix compatibility by running legacy systems on top of it well, namely linux hm... they have some UNIX compatibility at least... perhaps not aiming at full POSIX. don't remember the details Linux on genode? that's news to me... I know they do run genode on Linux anyway, i'll probably stick with the close unix approach for x15 http://genode.org/documentation/general-overview/ In an preliminary study, a user-level version of the Linux kernel (L4Linux) was successfully ported to the Genode OS Framework running on a L4 kernel. This study suggests that Genode combined with an appropriate kernel or hypervisor is suited as a virtual-machine hosting platform. hm... that's boring though ;-) isn't it :)