From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Thu 23 Oct 2003 - 00:11:34 BST
jack_at_solucorp.qc.ca (Jacques Gelinas) writes:
>> >> 1) set\control
>> > ...
>> > /proc should be used to do most of that.
>>
>> No, it is a pain for userspace tools
>> ...
>> This /proc-parsing method requires a proc-filesystem also
> ...
> Not convincing. If /proc fails to open and deliver, I really doubt anything
> will work.
Real world example: in rpm-fake.so, the execve() LD_PRELOAD wrapper for
rpm-scriptlets is called from within a chroot. When I would trust in the
told values, an attacker could return e.g. the number of a noop syscall,
the context-change would succeed seemingly and the scriptlet runs in ctx
0.
Most applications which are going into a chroot and changing the context
then, do not require /proc for their functionality but will fail since
they are relying on /proc.
And again; /proc parsing is ugly and error-prone.
>> > In the kernel, we only spit the various commands available and
>> > their version and userland tools can parse that. We keep the
>> > bload out of the kernel.
>>
>> Implementing the parsing of 'set' commands would be much more
>> bloat IMO...
>
> I was talking about version number and get the list of functionnalities,
> not the set.
Sorry, I thought your statement was about the '1) set\control'
also. But a mandatory read-only /proc interface would be still more
bloat than a syscall-interface (I do not speak about the 10 line
change in /proc/self/status; you will have to create a new entry
with an own handler).
Enrico
_______________________________________________
Vserver mailing list
Vserver_at_www.solucorp.qc.ca
http://www.solucorp.qc.ca/mailman/listinfo/vserver