On Mon, 2007-06-18 at 14:44 -0500, David Smith wrote: > Pavel Kankovsky wrote: > > On Mon, 11 Jun 2007, David Smith wrote: > > > >> (D) staprun.auth will need to disallow certain staprun.auth command-line > >> arguments, such as: > > > > Plus: > > > > - "-u USERNAME" (assuming you allow -c, otherwise it has no effect; > > on the other hand, its support in staprun can help to to make it > > possible to use -c via staprun.auth) The only reason for "-u" is so we can currently do things like >stap -c "make all" systrace.stp and have "make" execute as a normal user rather than root (because stap does "sudo staprun"). If staprun is not run by root, the setreuid() call will just fail if someone tries to misuse it. > > - "-t PID" (or "-x PID") (you need to disallow this because it is > > virtually impossible to avoid race conditions when you check whether > > a user is allowed to mess with a certain running process; alternatively, > > you can allow it and make it a requirement for blessed scripts that > > authorized users can attach them to any running process without > > compromising the security of the system) "-x pid "doesn't actually do anything except cause target() to return pid. So disabling it would be pointless. It exists as a convenient way to pass a value to scripts that wish to filter based on pid. > > BTW1: staprun should close the file descriptors it uses internally > > (control fd, relayfs fds) when it executes the target program given by -c. > > Good idea, I'll work on that. > > > BTW2: Let's suppose start_cmd() creates a process running under an > > unprivileged user. I think it can be killed (by the unprivileged user) > > before it gets SIGUSR1 and the system might recycle its pid. Therefore > > kill() in STP_START branch of stp_main_loop() is unsafe. > > Hmm. Got any ideas on how to fix this? So, while the module loads its probes, we kill the start_cmd() process and create enough new processes to recycle the pid? Then staprun sends either SIGKILL or SIGUSR1 to the wrong process? Theoretically, if we set tens of thousands of probes, we would have a few milliseconds to do this. Now that I've caught up on this discussion (sorry) I see we are simply talking about the blessed module approach to security. So the only issue here is how to load/unload the module, right? It seems like you have some good ideas. Why are we worrying about staprun? Load the module with your blessed loader, then staprun runs as a normal user. The only problem I see is unloading the module automatically. BTW, you can kind of try this now. Run with sudo or root: >sudo /sbin/insmod close.ko >sudo chown hunt.hunt /sys/kernel/debug/systemtap/close/* Now run staprun as a normal user >staprun -A close cpufreq-applet: close(17) = 0 cpufreq-applet: close(17) = 0 hald-addon-stor: close(4) = 0 cpufreq-applet: close(17) = 0 cpufreq-applet: close(17) = 0 crond: close(5) = 0 crond: close(5) = 0 gpm: close(0) = 0 cpufreq-applet: close(17) = 0 cpufreq-applet: close(17) = 0 DONE ERROR: Removing 'close': Operation not permitted ERROR: couldn't rmmod probe module close. -- Hmmm. So lets say we create stap_load owned by root, group systemtap, and file permission would be 04110. stap_load is a C program that does something like if (root) insmod(modname) else if modname is blessed && user is valid insmod(modname) endif stap_unload would be similar or it could be the same program with an argument to indicate load/unload. Then rename staprun to staprun.bin and create a script, staprun: if stap_load modname staprun.bin modname ... stap_unload modname endif Are there problems with this approach? Martin -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
