On Tue, Aug 31, 2004, Nadav Har'El wrote about Re: I'm not the process you think I
am:
You can try doing this with Linux's little-known capabilities feature.
This allows you to have any user id, but with some of root's capabilities,
like binding any network address or writing any file
On Tue, Aug 31, 2004, Nadav Har'El wrote about Re: I'm not the process you think I
am:
On second thought, while it's easy to have a root (uid 0) owned process
with lesser privelges (useful for enhanced security), it's less clear how
to use the capabilities mechanism to elevate the capabilities
On Tue, Aug 31, 2004 at 01:21:47PM +0300, Nadav Har'El wrote:
You can try doing this with Linux's little-known capabilities feature.
This allows you to have any user id, but with some of root's capabilities,
like binding any network address or writing any file (for example)
magically turned
On Tue, Aug 31, 2004 at 01:33:30PM +0300, Nadav Har'El wrote:
On Tue, Aug 31, 2004, Nadav Har'El wrote about Re: I'm not the process you think I
am:
You can try doing this with Linux's little-known capabilities feature.
This allows you to have any user id, but with some of root's
On Tue, Aug 31, 2004 at 12:56:50PM +0300, Muli Ben-Yehuda wrote:
Salutations!
I would like to have a process that will
- run with de-facto root priviledges (can do anything root can do)
- appears to be running under a different user with standard ps / top
and friends
Depending on whom you
On Tue, Aug 31, 2004 at 03:48:53PM +0300, Anatoly Vorobey wrote:
On Tue, Aug 31, 2004 at 12:56:50PM +0300, Muli Ben-Yehuda wrote:
Salutations!
I would like to have a process that will
- run with de-facto root priviledges (can do anything root can do)
- appears to be running under a
Muli Ben-Yehuda wrote:
On Tue, Aug 31, 2004 at 03:48:53PM +0300, Anatoly Vorobey wrote:
Depending on whom you wish to deceive (human or another program) and how
clever they are, you may want to try something as simple as
(oh-dear-God-I-don't-believe-I'm-gonna-say-it) naming uid 0 something
On Tue, Aug 31, 2004 at 04:33:40PM +0300, [EMAIL PROTECTED] wrote:
Muli - could you give a little more background on what are you trying to
achieve?
Make a process which is running with root capabilities appear in a
standard ps output as though it belongs to user 'foo'. I can't change
ps; I
Muli Ben-Yehuda wrote:
On Tue, Aug 31, 2004 at 04:33:40PM +0300, [EMAIL PROTECTED] wrote:
Muli - could you give a little more background on what are you trying to
achieve?
Make a process which is running with root capabilities appear in a
standard ps output as though it belongs to user
On Tue, 31 Aug 2004, Muli Ben-Yehuda wrote:
On Tue, Aug 31, 2004 at 04:33:40PM +0300, [EMAIL PROTECTED] wrote:
Muli - could you give a little more background on what are you trying to
achieve?
Make a process which is running with root capabilities appear in a
standard ps output as though
On Tue, Aug 31, 2004 at 05:21:45PM +0300, Alon Altman wrote:
Can you load a kernel module? If so, you can load one that intercepts the
access to the /proc filesystem.
Nope, that as well as any other method of patching the running kernel
(there are several...) is covered by the no kernel
On Tue, Aug 31, 2004 at 05:34:15PM +0300, Anatoly Vorobey wrote:
Can you surreptitiously modify LD_PRELOAD for the user who'll be running
ps/top (by modifying their startup files or whatever)? If you can, write
a tiny library that redirects open() to itself and, in
case a process is trying
On Tue, Aug 31, 2004 at 06:52:51PM +0300, Gilad Ben-Yossef wrote:
Make a process which is running with root capabilities appear in a
standard ps output as though it belongs to user 'foo'. I can't change
ps; I can't change the kernel. I can only use the standard POSIX
APIs. I do have root on
On Tue, Aug 31, 2004 at 06:42:35PM +0300, Muli Ben-Yehuda wrote:
Can you surreptitiously modify LD_PRELOAD for the user who'll be running
ps/top (by modifying their startup files or whatever)? If you can, write
a tiny library that redirects open() to itself and, in
case a process is
On Tue, Aug 31, 2004 at 08:15:56PM +0300, Anatoly Vorobey wrote:
[nitpicking follows]
[nitpickers are us]
I'm not suggesting replacing the file (impossible in /proc w/o changing
the kernel or the mounting), I'm suggesting replacing the
*descriptor*.
I'm not suggesting replacing the file
On Tue, Aug 31, 2004 at 09:41:46PM +0300, Muli Ben-Yehuda wrote:
On Tue, Aug 31, 2004 at 08:15:56PM +0300, Anatoly Vorobey wrote:
[nitpicking follows]
[nitpickers are us]
The nits have all been picked now, and no disagreements remain.
While we're at it though, here's a considerably
Muli Ben-Yehuda wrote:
Agreed, in this specific case. I was thinking ps/top might be doing
something funky with the /proc/$PID/* files they read, but it looks
like a very simple open/read/close, e.g.:
open(/proc/6/cmdline, O_RDONLY) = 8
read(8, , 2047) = 0
close(8)
So
Muli Ben-Yehuda wrote:
Nah, I consider kernel modules just a semi-organized way of patching
the kernel, and kernel changes are not allowed.
*insert standard rant about why oh, we don't modify the kernel, we
just load a driver! doesn't mean squat in Linux, and it very much
_does_ modify the
On Tue, Aug 31, 2004 at 10:06:02PM +0300, Shachar Shemesh wrote:
Is this a bet with someone? If so, would consulting a user group be
considered cheating? If so, can I squirm you out of another dinner for
keeping it secret? :-)
Heh, there's a real world problem there, trust me. If it wasn't
19 matches
Mail list logo
