Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
The most important use-case is to make it possible to run scripts when even /bin/sh is not available. Such as %pretrans scripts on initial install - there simply nothing to exec() in that environment. Or if the package containing /bin/sh or one of its dependencies needs scripts, there's no other choice than an embedded script during initial install. Related to that, one can avoid problematic external dependencies in the early bootstrap stages of initial install. It also allows some things that aren't really possible otherwise, such as manipulating macros and communicating with other packages through the global Lua environment (and in theory, accessing rpmdb but that's not implemented), which would not be possible in an externally executed script. It would be possible to fork() for the execution of embedded scripts without compromising the main use-case of early install, but it would break some possible uses of the second group. Whether that's a good or bad thing... is a different question. I dunno if anybody is actually using the current possibilities in that area. Thank you for explaining! Now I start to understand this a bit better. Providing better interfaces and possibilities for trusted packages to do needed things is always good, I guess the only thing would be to have the possibility for a plugin to implement restrictions if necessary. I agree that it would be better to make some decision on per script/package basis whenever this lua script is allowed to run and with what privileges instead of simply saying disable lua at compile time . I think the solution that plugin would return an error code n pre-script execution if it thinks that lua scipts aren't allowed is actually an acceptable one for now. The better one would be only to setup the security context but this would require the fork(). Good question... symmetry is usually good, so I guess the post-hook should be always called if pre-hook was called. Script path + return code as arguments seems like a reasonably starting point at least. (I'm not really even dreaming of getting every single detail 100% right the first time :) Ok, I will do it this way. I actually have these changes ready, but wanted to finish with three main filesystem hooks at the same time. I am hoping to do it this week. And like said, I think the plugin hooks should get called with embedded scripts too. It'll probably need another argument to let the plugins know whether an internal or external script is about to be executed - you could eg just deny execution of internal scripts from non-trusted sources then, without disabling lua entirely. Yes, I agree, this is a better alternative to a complete lua disabling. I will do it this way. Do you want the script changes in separate path then without any filesystem hooks? Best Regards, Elena. smime.p7s Description: S/MIME cryptographic signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH RFC] Package script(let)s SELinux execution context
Hi!
Some context for the rpm folks. While looking into improving SELinux
support in dpkg, I noticed that dpkg is not setting a new execution
context when running the package maintainer scripts (package scriptlets
in rpm lingo, I think). And when checking how to implement it, it seemed
that reusing something like the current rpm_execcon() would be best,
and Stephen seemed to agree. For more details, see the thread starting
at http://marc.info/?t=13523635871r=1w=2.
Having checked the rpm code, and the mailing list, it seems like this
new function would make it easy to be used there too for stuff like
the Lua scriptlets (if desired), and might make it easier also to
switch to the new rpm plugins framework (?).
I've discarded the verified argument for the new function because that
seemed best handled from the rpm side, and in any case seemed unrelated
to the execution context. I'm not entirely convinced about the function
name though, as it could be confused as applying a context to a path on
the filesystem. And I've not marked rpm_execcon() as deprecated because
it might be annoying at the beginning, but would change that if you think
it makes sense.
In any case, here's a patch adding such new function. For dpkg, given
that it has never set a new context up to now, I'd only make use of the
function if it's available in libselinux, as I don't think it's worth it
to ship an embedded copy. For rpm, I guess it could switch to use the
function also if available and fallback to rpm_execcon() otherwise. After
a while the rpm_execcon() function could be removed from libselinux, on
the next ABI break, as I understand was the plan anyway (?).
(The patch might not apply w/o the man page cleanup series.)
So, what do you think?
Thanks,
Guillem
Guillem Jover (1):
libselinux: Refactor rpm_execcon into a new setexecfilecon()
libselinux/Makefile| 3 +++
libselinux/include/selinux/selinux.h | 4
libselinux/man/man3/getexeccon.3 | 23 ---
libselinux/src/Makefile| 3 ---
libselinux/src/{rpm.c = setexecfilecon.c} | 27 ---
5 files changed, 47 insertions(+), 13 deletions(-)
rename libselinux/src/{rpm.c = setexecfilecon.c} (71%)
--
1.8.0
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH] libselinux: Refactor rpm_execcon() into a new setexecfilecon()
This new function allows a process to invoke helper programs with
a new execution context based on the filename, this is initially
intended for package managers so that they can easily execute
package scriptlets or maintainer scripts.
Base rpm_execcon() off this new function.
Signed-off-by: Guillem Jover guil...@debian.org
---
libselinux/Makefile| 3 +++
libselinux/include/selinux/selinux.h | 4
libselinux/man/man3/getexeccon.3 | 23 ---
libselinux/src/Makefile| 3 ---
libselinux/src/{rpm.c = setexecfilecon.c} | 27 ---
5 files changed, 47 insertions(+), 13 deletions(-)
rename libselinux/src/{rpm.c = setexecfilecon.c} (71%)
diff --git a/libselinux/Makefile b/libselinux/Makefile
index fd4f0b1..6142b60 100644
--- a/libselinux/Makefile
+++ b/libselinux/Makefile
@@ -16,6 +16,9 @@ endif
ifeq ($(DISABLE_BOOL),y)
EMFLAGS+= -DDISABLE_BOOL
endif
+ifeq ($(DISABLE_RPM),y)
+ EMFLAGS+= -DDISABLE_RPM
+endif
ifeq ($(DISABLE_SETRANS),y)
EMFLAGS+= -DDISABLE_SETRANS
endif
diff --git a/libselinux/include/selinux/selinux.h
b/libselinux/include/selinux/selinux.h
index 6b9089d..e1e965d 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -565,6 +565,10 @@ int selinuxfs_exists(void);
/* clear selinuxmnt variable and free allocated memory */
void fini_selinuxmnt(void);
+/* Set an appropriate security context based on the filename of a helper
+ * program, falling back to a new context with the specified type. */
+extern int setexecfilecon(const char *filename, const char *fallback_type);
+
/* Execute a helper for rpm in an appropriate security context. */
extern int rpm_execcon(unsigned int verified,
const char *filename,
diff --git a/libselinux/man/man3/getexeccon.3 b/libselinux/man/man3/getexeccon.3
index c188a3a..1b66ab6 100644
--- a/libselinux/man/man3/getexeccon.3
+++ b/libselinux/man/man3/getexeccon.3
@@ -15,6 +15,8 @@ rpm_execcon \- run a helper for rpm in an appropriate
security context
.sp
.BI int setexeccon_raw(security_context_t context );
.sp
+.BI int setexecfilecon(const char * filename , const char * fallback_type
);
+.sp
.BI int rpm_execcon(unsigned int verified , const char * filename , char
*const argv [] , char *const envp []);
.
.SH DESCRIPTION
@@ -62,7 +64,21 @@ Signal handlers that perform an
must take care to
save, reset, and restore the exec context to avoid unexpected behavior.
+.BR setexecfilecon ()
+sets the context used for the next
+.BR execve (2)
+call, based on the policy for the
+.IR filename ,
+and falling back to a new context with a
+.I fallback_type
+in case there is no transition.
+
.BR rpm_execcon ()
+is deprecated; please use
+.BR setexecfilecon ()
+in conjunction with
+.BR execve (2)
+in all new code. This function
runs a helper for rpm in an appropriate security context. The
verified parameter should contain the return code from the signature
verification (0 == ok, 1 == notfound, 2 == verifyfail, 3 ==
@@ -76,10 +92,11 @@ environment arrays.
On error \-1 is returned.
On success
-.BR getexeccon ()
-and
+.BR getexeccon (),
.BR setexeccon ()
-returns 0.
+and
+.BR setexecfilecon ()
+return 0.
.BR rpm_execcon ()
only returns upon errors, as it calls
.BR execve (2).
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index ac019df..a7e5311 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -47,9 +47,6 @@ endif
ifeq ($(DISABLE_BOOL),y)
UNUSED_SRCS+=booleans.c
endif
-ifeq ($(DISABLE_RPM),y)
- UNUSED_SRCS+=rpm.c
-endif
GENERATED=$(SWIGCOUT) $(SWIGRUBYCOUT) selinuxswig_python_exception.i
SRCS= $(filter-out $(UNUSED_SRCS) $(GENERATED) audit2why.c, $(wildcard *.c))
diff --git a/libselinux/src/rpm.c b/libselinux/src/setexecfilecon.c
similarity index 71%
rename from libselinux/src/rpm.c
rename to libselinux/src/setexecfilecon.c
index b89f1bb..b3afa13 100644
--- a/libselinux/src/rpm.c
+++ b/libselinux/src/setexecfilecon.c
@@ -5,15 +5,14 @@
#include selinux_internal.h
#include context_internal.h
-int rpm_execcon(unsigned int verified __attribute__ ((unused)),
- const char *filename, char *const argv[], char *const envp[])
+int setexecfilecon(const char *filename, const char *fallback_type)
{
security_context_t mycon = NULL, fcon = NULL, newcon = NULL;
context_t con = NULL;
int rc = 0;
if (is_selinux_enabled() 1)
- return execve(filename, argv, envp);
+ return 0;
rc = getcon(mycon);
if (rc 0)
@@ -28,12 +27,12 @@ int rpm_execcon(unsigned int verified __attribute__
((unused)),
goto out;
if (!strcmp(mycon, newcon)) {
- /* No default transition, use rpm_script_t for now. */
+ /* No default transition, use fallback_type for now. */
rc = -1;
Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
On 11/20/2012 01:45 PM, Reshetova, Elena wrote: The most important use-case is to make it possible to run scripts when even /bin/sh is not available. Such as %pretrans scripts on initial install - there simply nothing to exec() in that environment. Or if the package containing /bin/sh or one of its dependencies needs scripts, there's no other choice than an embedded script during initial install. Related to that, one can avoid problematic external dependencies in the early bootstrap stages of initial install. It also allows some things that aren't really possible otherwise, such as manipulating macros and communicating with other packages through the global Lua environment (and in theory, accessing rpmdb but that's not implemented), which would not be possible in an externally executed script. It would be possible to fork() for the execution of embedded scripts without compromising the main use-case of early install, but it would break some possible uses of the second group. Whether that's a good or bad thing... is a different question. I dunno if anybody is actually using the current possibilities in that area. Thank you for explaining! Now I start to understand this a bit better. Providing better interfaces and possibilities for trusted packages to do needed things is always good, I guess the only thing would be to have the possibility for a plugin to implement restrictions if necessary. I agree that it would be better to make some decision on per script/package basis whenever this lua script is allowed to run and with what privileges instead of simply saying disable lua at compile time . I think the solution that plugin would return an error code n pre-script execution if it thinks that lua scipts aren't allowed is actually an acceptable one for now. Plugins being able to deny scriptlet execution on per-package (or scriptlet) basis seems entirely reasonable to me, considering the goals discussed here. Regardless of whether its embedded lua or a normal scriptlet. The better one would be only to setup the security context but this would require the fork(). I'm starting to think we'll want the ability to fork lua execution anyway. I've just been pondering over the details: simply always forking Lua scriptlets would make a whole lot of sense and eliminate the need to try and protect rpm from the things lua scripts can do. But like said, that would break any lua scriptlets depending on the in-process execution. Which might actually be just a good thing in a way. Another possibility is making the forking configurable, but its fairly ugly and wouldn't allow us to get rid of the fragile try save and restore any damage lua might do to us stuff. Good question... symmetry is usually good, so I guess the post-hook should be always called if pre-hook was called. Script path + return code as arguments seems like a reasonably starting point at least. (I'm not really even dreaming of getting every single detail 100% right the first time :) Ok, I will do it this way. I actually have these changes ready, but wanted to finish with three main filesystem hooks at the same time. I am hoping to do it this week. And like said, I think the plugin hooks should get called with embedded scripts too. It'll probably need another argument to let the plugins know whether an internal or external script is about to be executed - you could eg just deny execution of internal scripts from non-trusted sources then, without disabling lua entirely. Yes, I agree, this is a better alternative to a complete lua disabling. I will do it this way. Do you want the script changes in separate path then without any filesystem hooks? Smaller sets are always preferred as they're easier to review. If you have the scriptlet stuff ready, just fire away :) - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH RFC] Package script(let)s SELinux execution context
On 11/20/2012 05:27 PM, Guillem Jover wrote: Hi! Some context for the rpm folks. While looking into improving SELinux support in dpkg, I noticed that dpkg is not setting a new execution context when running the package maintainer scripts (package scriptlets in rpm lingo, I think). And when checking how to implement it, it seemed that reusing something like the current rpm_execcon() would be best, and Stephen seemed to agree. For more details, see the thread starting at http://marc.info/?t=13523635871r=1w=2. Having checked the rpm code, and the mailing list, it seems like this new function would make it easy to be used there too for stuff like the Lua scriptlets (if desired), and might make it easier also to switch to the new rpm plugins framework (?). I've discarded the verified argument for the new function because that seemed best handled from the rpm side, and in any case seemed unrelated to the execution context. I'm not entirely convinced about the function name though, as it could be confused as applying a context to a path on the filesystem. And I've not marked rpm_execcon() as deprecated because it might be annoying at the beginning, but would change that if you think it makes sense. In any case, here's a patch adding such new function. For dpkg, given that it has never set a new context up to now, I'd only make use of the function if it's available in libselinux, as I don't think it's worth it to ship an embedded copy. For rpm, I guess it could switch to use the function also if available and fallback to rpm_execcon() otherwise. After a while the rpm_execcon() function could be removed from libselinux, on the next ABI break, as I understand was the plan anyway (?). (The patch might not apply w/o the man page cleanup series.) So, what do you think? No objections to replacing and/or axing rpm_execcon(), AFAIR its simply a convenience-function around setexeccon() and one that rpm will (have to) cease to use in near future anyway in order to move all the selinux specifics into a plugin. I dont have objections for the suggested interface as such either, it'd be convenient for what rpm will need for regular scriptlets. It wont help with rpm's embedded Lua-scriptlets as they run in-process though. Rpm might well start forking their execution, but even then the transition to another selinux context (or similar security mechanism) needs to happen without an exec() for the embedded scripts. - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH RFC] Package script(let)s SELinux execution context
On 11/20/2012 07:27 PM, Panu Matilainen wrote: On 11/20/2012 05:27 PM, Guillem Jover wrote: Hi! Some context for the rpm folks. While looking into improving SELinux support in dpkg, I noticed that dpkg is not setting a new execution context when running the package maintainer scripts (package scriptlets in rpm lingo, I think). And when checking how to implement it, it seemed that reusing something like the current rpm_execcon() would be best, and Stephen seemed to agree. For more details, see the thread starting at http://marc.info/?t=13523635871r=1w=2. Having checked the rpm code, and the mailing list, it seems like this new function would make it easy to be used there too for stuff like the Lua scriptlets (if desired), and might make it easier also to switch to the new rpm plugins framework (?). I've discarded the verified argument for the new function because that seemed best handled from the rpm side, and in any case seemed unrelated to the execution context. I'm not entirely convinced about the function name though, as it could be confused as applying a context to a path on the filesystem. And I've not marked rpm_execcon() as deprecated because it might be annoying at the beginning, but would change that if you think it makes sense. In any case, here's a patch adding such new function. For dpkg, given that it has never set a new context up to now, I'd only make use of the function if it's available in libselinux, as I don't think it's worth it to ship an embedded copy. For rpm, I guess it could switch to use the function also if available and fallback to rpm_execcon() otherwise. After a while the rpm_execcon() function could be removed from libselinux, on the next ABI break, as I understand was the plan anyway (?). (The patch might not apply w/o the man page cleanup series.) So, what do you think? No objections to replacing and/or axing rpm_execcon(), AFAIR its simply a convenience-function around setexeccon() and one that rpm will (have to) cease to use in near future anyway in order to move all the selinux specifics into a plugin. I dont have objections for the suggested interface as such either, it'd be convenient for what rpm will need for regular scriptlets. It wont help with rpm's embedded Lua-scriptlets as they run in-process though. Rpm might well start forking their execution, but even then the transition to another selinux context (or similar security mechanism) needs to happen without an exec() for the embedded scripts. To clarify: currently the embedded Lua-scriptlets run in the context of rpm itself with no context changes whatsoever. So the proposed interface change would by no means be a loss to rpm, but it doesn't help the situation with embedded scriptlets. Doesn't make it any worse either :) - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
