IRC channel logs

<damo22>my smp program needs root to get the privileged ports, but is there an easy way to drop root privileges back to the user that called sudo?

<youpi>you have the SUDO_USER env

<solid_black>don't do that, use setuid

<damo22>solid_black: i dont understand

<solid_black>make your executable setuid, i.e. chmod u+s /bin/smp

<youpi>with the suid bit you'd use getuid() instead, to set back to the user privileges

<solid_black>and in the code, call setuid(getuid()), or something like that

<solid_black>yes

<damo22>i was looking at setuid(2)

<solid_black>setuid(2) and the setuid bit in st_mode are related but distinct concepts

<solid_black>youpi: what's the plan with MAP_NORESERVE / overcommit support?

<youpi>implement overcommit, unless map_noreserve is set

<youpi>cf the contributing.mdwn line about it

<solid_black>MAP_NORESERVE exactly means don't track/reserve any memory for this, and prefer to crash the process if there turns out to be not enough physical memory for when this mapping is accessed

<solid_black>but I don't think Mach currently does any sort of memory accounting?

<youpi>that's why I'm saying "implement" :)

<solid_black>is darnassus down?

<solid_black>I can't seem to access the wiki

<solid_black>but -- how do you imagine this might work? isn't this the whole resource accounting issue that is practically unsolvable in Mach?

<youpi>it's not

<youpi>the question at stake is the mallocs()/mmaps() that the process does

<youpi>which is fully accountable

<youpi>what people have been shouting about is other resources

<youpi>like if you run thousands of selects() and whatnot

<youpi>which all other oses actually have troubles with too, anyway

<solid_black>ok, but you'd want to give groups of tasks "physical memory allowance" or something, so an unprivileged task cannot eat up all of the systems' memory

<youpi>they are more at ease to account for them

<solid_black>basically like cgroups in linux

<youpi>but they don't really do that, really

<youpi>there's no need to invent something fancy

<solid_black>and then it turns out that with our client/server architecture and tasks being able to send memory pages to each other, it doesn't really work

<youpi>just implementing the usual overcommit limitation will already be plenty

<solid_black>so an unprivileged user can commit all of the system's memory and then cause core server's mmap to fail?

<youpi>no

<youpi>the ratio is usually 0.5

<youpi>again, see contributing.mdwn

<youpi>and man proc_sys_vm

<solid_black>trying to :D

<solid_black>"Add overcommit limitation support to gnumach: limit the virtual size of processes to half of the memory + swap size."

<solid_black>so again, how can this work without making it possible (and probable) for a bunch of unprivileged processes to claim all the allowed memory, which would then prevent actually important tasks like core servers from doing anything

<youpi>nasty processes can do nasty things, yeah

<youpi>that's all the same on linux

<youpi>usually you only have one of them, and it just crashes, good for it

<damo22>solid_black: trust your shell users

<youpi>I didn't write it in the list, but at some point we'd want an oom killer, without would of course avoid the important processes

<solid_black>on the contrary, it'd be great if we could somehow do this properly, so we could, for instance, set up a public server that anyone could ssh into

<youpi>s/without/which

<youpi>I don't think we'd ever be able to trustfully do such a thing

<youpi>there are way too many software layers that can introduce safety issues

<youpi>ideally the hurd model would isolate things

<youpi>and probably we can do better than linux

<youpi>but I still wouldn't trust it enough to put it in the open for people to hack into

<solid_black>an idea I had is to give everyone their own subhurd

<solid_black>since subhurds are pretty isolated, so the exposed potential for exploitation is a lot smaller

<solid_black>but still, all of Mach is exposed (and reminder that there's still that unfixed kernel memory write...)

<youpi>patches welcome

<solid_black>and the lack of resource accounting makes it possible for a subhurd to claim all of the memory / CPU time resources

<damo22>im worried about never getting to execute in parallel and youre worried about running too much

<youpi>it's fine to discuss about this, but that's longterm. What is short-term is dumb processes that allocate crazy-lot memory, which is easy to fix by just implementing overcommit check

<youpi>that won't magically solve security issues

<youpi>but that'll fix now-issues

<youpi>and cannot hurt, since other OSes do that, so people are used to it

<damo22>i fixed a bug with hurd debian package, acpi is missing link with irqhelp

<damo22>i dont know how you managed to build it

<solid_black>hm, so setuid rewrites the first two entries of aux uids, which makes sense

<solid_black>but that means it could leave more instances of uid=0 in that array if they happen to be present there for some reason

<solid_black>and a unix program would have no idea, and believe it has dropped privs

<youpi>it overwrites the others as well, for compatibility with such programs

<youpi>doesn't it?

<youpi>at least it should

<solid_black>does it? I'm looking at glibc:sysdeps/mach/hurd/setuid.c:68

<youpi>(I'm talking about sid / fsid )

<youpi>I'm just talking about how posix does it

<youpi>I don't remember the details how hurd defined the other uids, which can indeed pose problem

<solid_black>fsid is a linuxism afair, it's not in either posix or the hurd

<youpi>doesn't matter, there's sid too

<youpi>I just mean the principle of setting them on setuid() when you introduce them

<youpi>damo22: does acpi actually use it?

<solid_black>for us, 'The first available id is conventionally called the "real" id, and the second the "saved" id.'

<damo22>youpi: yes

<youpi>I don't see it use it

<damo22>hmmm

<solid_black>so 'newaux[0] = newaux[1] = uid;' does set both real uid and saved uid, but not the other avaialble uids

<damo22>youpi: libacpica uses it

<youpi>that's only recent

<solid_black>_hurd_reauth hook is also fun, I don't think there's any order guaranteed for the elements of a hook

<solid_black>which means when dropping privileges with setauth (from setuid), we might reauth with proc server before we reauth all of our fds

<solid_black>with the obvious consequences

<damo22>youpi: i didnt think it would be good to add "-lirqhelp" to libacpica_LIBS but instead use the HURD_LIBS variable for that

<youpi>I'm just answering why it did link when I last built the hurd package

<damo22>thanks

<youpi>(normally libacpica would provide a pkgconfig file to expose that -lirqhelp is needed for static link)

<solid_black>so what would be an easy to exploit binary that is suid and drops privileges? /bin/ping perhaps?

<damo22>what stops an attacker running a suid binary in gdb and inserting malware?

<solid_black>damo22: gdb won't be able to control a suid binary

<damo22>ok

<solid_black>when you execve() a suid binary, the task & process ports are invalidated

<solid_black>physically, it runs in a new Mach task

<solid_black>but it's the same Unix process

<solid_black>but a different process *port*

<damo22>what stops a user building a package that installs a suid binary of their choice and installing it?

<solid_black>nothing, but they need root access to install packages

<solid_black>as a sysadmin, you can install malicious software if you so choose, yes

<damo22>but cant they install it onto a subhurd

<solid_black>yes, then they will get root in the subhurd

<damo22>if they mount /

<solid_black>you can't quite mount / in a subhurd

<damo22>i mean is it bad for them to have root in a subhurd?

<solid_black>think of it this way: if you can write an arbitrary file onto / as root, you can do anything

<solid_black>you don't need a suid binary to do that

<solid_black>if you cannot write an arbitrary file onto / as root, you cannot write a suid-root binary in particular

<solid_black>does that make sense?

<damo22>not sure

<solid_black>suid also doesn't have to be *suid root* -- any user can make a binary that will be *setuid them*

<solid_black>which enables other users that have the 'x' permission to run the binary with uid=owner

<solid_black>root is just the most common use case of this mechanism

<solid_black>if it doesn't make perfect sense, don't worry, there are no obvious holes (like attaching gdb or installing a package) in this meachnism, but there is a long & neverending chain of subtle not-so-obvious holes caused by it

<damo22>im building hurd package with ./smp

<damo22>to make sure it installs the binary

<damo22>once it all works i will send in patch

<solid_black>it should be in hurd-extras perhaps?

<damo22>there is hurd/sutils

<damo22>containing a few useful binaries

<damo22>hurd specific

<Pellescours>damo22: I don’t know if you changed the smp program (than the one you sent in March/April), but if it’s the same, I recommend to add a proper verification of the arguments number because calling "smp" without argument cause a segfault (because it assume at least 1 argument)

<janneke>=> https://lists.gnu.org/archive/html/guix-devel/2024-11/msg00235.html

<janneke>my blog post about hurd on real iron, for those who haven't seen it yet

<solid_black>janneke: please consider not referring to the Hurd on x86_64 as "64-but Hurd", naming things "hurd64" etc

<solid_black>we're going to have more 64-bit ports, not just x86_64

<solid_black>otherwise, amazing work :)

<janneke>solid_black: yeah, the aarch64 and risc-v64 will also be 64bit hurds one day

<solid_black>so maybe plan for that and name your image hurd-x86_64.qcow2, not hurd64.qcow2 -- is my point

<user_oreloznog>Nice blog post!

<janneke>solid_black: hmm, i see what you mean

<janneke>the current i586 one, is called "hurd" so yeah, hopefully we'll get into trouble over that some time soon :)

<janneke>user_oreloznog: thanks!

<user_oreloznog>:)

<janneke>solid_black: thanks for the feedback, i'll pass this round in our team

<janneke>user_oreloznog: i'm just the packager here :)

<user_oreloznog>janneke: I know, thanks also to others!

<janneke>certainly!

<slex>a

<sneek>slex, you have 1 message!

<sneek>slex, azert says: a driver for what block device?

<slex>sneek: ata disk (IDE) something simple

<solid_black>(again, not that I know anything about IDE), but I do think it would be valuable to have our own / alternative IDE driver that is neither rumpdisk nor dde

<solid_black>assuming it's not a huge lot of work, and that slex is interested in working on it

<solid_black>slex: do you have experience/understanding of how you would write the driver if it wasn't for the Hurd, but for some other kernel, i.e. without Hurd specifics?

<slex>yes i did wrote one for my little toy kernel, but hurd that is in userspace need some differences

<slex>my toy kernel was a monolithic one while hurd runs on top of a microkernel

<solid_black>I should be able to help you with many Hurd specifics

<slex>well i have to understand a bit better mach before writing for the hurd i will explain in few time the idea

<slex>and i'm not sure that would be the best way

<solid_black>please feel free to ask questions; even if I'm unable answer them, someone else might be

<slex>This is the plan: let's assume i have only the kernel no glibc and no hurd; i have to write this simple driver. The architecture i thought is the following: The userspace block driver it's started by the kernel tha parses the grub argument, so at first run it must init the device. For the code i did read it seems that i need to interact with the kernel. I thought at an IPC interface that sends the request to a kernel thread (the loop that handles the device

<slex>requests) sending in the message a name like hd0a (char*), then the kernel searches for the devic (dev_lookup()?) and if it does not exists it creates the device (struct device) and sends it back as reply

<slex>is this making sense?

<solid_black>no

<solid_black>that's not how things work

<solid_black>your driver is a program that runs in userland, so yes there is a libc

<solid_black>and all the other Hurd libraries

<solid_black>you don't even need to interact with Mach much, certainly not to insert your device into its list

<solid_black>nor should you be concerned with parsing anything coming from grub

<solid_black>that is all handled by other parts of the system

<solid_black>is _that_ making sense now? :)

<solid_black>I guess the part that you misunderstood is that every device implemented by any driver anywhere is accessible by device_open() on the device master port

<solid_black>but that's only true for kernel-implemented drivers, of which there ideally should be as little as possible

<slex>yes device_open that calls devv_lookup() via the master_port and getting the device port. This is what is confusing me.

<solid_black>yes, so you shouldn't be looking at that

<solid_black>that's not how other things on the system will be looking up your device

<solid_black>that's only for kernel-implemented devices, which yours is not

<slex>ok, but i want assume i have nothing just the kernel :) it's something starting from scratch because i need to understand in the deep :)

<slex>so i don't have to use device_open(). And how i write to the disk?

<slex>from userpace

<solid_black>you should assume you have other things avaialble to you, and use them

<slex>ok say me what so i read the code :)

<solid_black>for instance from what I could quickly find online, IDE is based on PCI, right? so you'll use libpciaccess and/or Hurd's pci-arbiter

<slex>ok ty

<slex>i will read the code as a good starting point

<solid_black>if what you're asking is how other programs will access the device implemented by you, it could be something as simple as them opening /dev/hda1 (assuming that's what your driver implements) and reading/writing to that

<solid_black>if you want your driver to be used in early boot (meaning, to support booting the GNU/Hurd system off a drive managed by your driver), it's somewhat more involved

<solid_black>damo22 is teh expert here

<slex>yes the drive must manage the boot, step by step obviously :) maybe i can just attach anothe virtual hd (hdb1) and playing there

<slex>*driver

<solid_black>yes, you should start by getting it to work on a system that's already booted from another drive, using another driver

<slex>yes that's the plan

<slex>and maybe also playing in a less developed mach version, that would be easier to understand? Maybe the early versions of mach 4?

<solid_black>no, you don't want that

<solid_black>really, you shouldn't care much about Mach at all

<solid_black>do care about the Hurd

<slex>(need to be off for work see you later, i'll read the messages when i will be on again)

<solid_black>sure

<solid_black>I mean, unless I misunderstood your goal entirely

<slex>ty

<solid_black>if what you want in the end is a disk driver for the Hurd, then the way to go is ignoring most of Mach's abstractions/internals, and using the Hurd's interfaces and libraries, as I'm telling you

<solid_black>you're probably still going to implement the device_* APIs, using libmachdev

<solid_black>so yes, please look into libpciaccess, libmachdev, and talk to damo22

IRC channel logs

2024-11-25.log