Re: RFE: (security) hooks for script execution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Enrico --

Poke the same message(s) onto <rpm-devel@xxxxxxxxxxxxxxxxxxxx> please.

General lua hooking on all RPMRC_FOO returns, with fine grained
hook dispatch through a namespace table, and dlopen to accomodate
language implementation issues from lua (hint: embedding is not
hard, lua first) embedded layer, is what is needed in rpmlib, not
(your otherwise perfectly sensible) but rather limited request.

73 de Jeff

On Fri, Feb 04, 2005 at 03:11:52PM +0100, Enrico Scholz wrote:
> Hello,
> 
> I use rpm to manage so-called vservers [1] which are basically secure chroot
> environments. Script execution could lower this security significantly as the
> scripts will be e.g. executed with full host rights. Therefore, I developed a
> hack[2] which overrides the execv(3) and rpm_execcon(3) functions.
> 
> Unfortunately, this relies on some unportable assumptions and will probably
> break with the upcoming lua script integration.
> 
> So my proposal for security hooks:
> 
> 1. create a macro which allows to specify a dynamic library; e.g.
> 
>    %_hook_library    /usr/lib/util-vserver/rpmhooks.so
> 
>    This library has an API consisting of
> 
>    | void * rpmhook_init();
>    | int    rpmhook_preChroot(void *state, char const *chroot);
>    | int    rpmhook_preExec(void *state, int argc, char *argv[]);
> 
> 
> 2. rpmlib initialization executes something like:
> 
>    | char const   lib[PATHMAX];
>    | strcpy(lib, "%_hook_library");
>    | expandMacros(..., lib, ...);
>    | ...
>    | void *handle = dlopen(lib);
>    | void *(*hook_init)() = dlsym(lib, "rpmhook_init");
>    | <some global state>->hook_pre_chroot = dlsym(lib, "rpmhook_preChroot");
>    | <some global state>->hook_pre_exec   = dlsym(lib, "rpmhook_preExec");
>    |
>    | <some global state>->hook_data = (*hook_init)();
> 
> 3. every script execution (inclusive the lua one) must happen in an own
>    process, so the responsible child would execute:
> 
>    | if (pid==0) {
>    |   void *data = <some global state>->hook_data;
>    |   ...
>    |   if (<some global state>->hook_pre_chroot &&
>    |       <some global state>->hook_pre_chroot(data, chroot_dir)==-1)
>    |     ERROR(...)
>    |   chroot(chroot_dir);
>    |   ...
>    |   if (<some global state>->hook_pre_exec &&
>    |       <some global state>->hook_pre_exec(data, argc, argv)==-1)
>    |     ERROR(...)
>    |   execve(argc, argv, environ);
> 
> 
> (I have not looked at the code to determine the exact variable names and
> I am not sure, what there can be used for '<some global state>')
> 
> 
> This method would solve the SELinux issues with '--root' also [3], as
> the context switch could be done in the pre-chroot hook where '/proc' is
> still available.
> 
> As an extension, '%_hook_library' and the related hooks could be a list
> so that the multiple actions are possible.
> 
> 
> Has this proposal a chance to be accepted, or would it be wasted time to
> work on a patch? Details which must be cleared are e.g.
> 
> * the naming of the hook functions
> * the exact API of the hooks; I see that rpm_execcon(3) requires at
>   least a 'verified' field.
> * which rpmlib function can be used for the initialization part
> * what can be used for '<some global state>
> * how is/will LUA be integrated
> 
> 
> 
> 
> Enrico
> 
> Footnotes: 
> [1]  http://www.linux-vserver.org
> [2]  http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/src/rpm-fake.c?rev=HEAD
> [3]  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145770
> 
> 



> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/rpm-list

-- 
Jeff Johnson	ARS N3NPQ
jbj@xxxxxxxxxx (jbj@xxxxxxx)
Chapel Hill, NC

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux