When writing policy, they are sometimes hard to detect especially if you do not know what to look for. This is one reason the review process of policy writing is good. Problems like leaked file descriptors show the weakness in tools that automatically generate policy, since the default would be allow access to the leaked descriptors.
One of the new features in Fedora Core 5 was the inclusion of the executable memory checking for unconfined applications. These checks are looking for places in code where memory could be written to and executed. Buffer overflows take advantage of programs that allow this to happen. The goal of almost every exploit is to execute the crackers own code. This is one of the main ways crackers have been able to break into systems. In the FC4 time frame we added checks for execmem, execmod, execheap, and execstack. We also added a boolean for each one of these memory checks: allow_execmem, allow_execmod, allow_execheap, allow_execstack. All of these booleans were turned on by default. This allowed all unconfined domains to run even if the kernel discovered an application of library that was coded incorrectly. Confined domains for the most part did not allow these accesses.
Ulrich Drepper has writing extensively on how to improve programming practices and the overall quality of the code, pushed hard to change these rules to be denied by default. This would allow us to improve the overall security of the system and allow us to find and clean up badly written programs. So in FC5, we turned off the boolean allow_execheap and allow_execmod. In Rawhide, we currently have allow_execstack and allow_execmem turned off also.
You as a user could turn these booleans on or off by executing.
setsebool -P allow_execmod=1 or setsebool -P allow_execmod=0
For each boolean.
Now lets delve further into these checks. Ulrich wrote up a technical explanation of these checks in http://people.redhat.com/~drepper/selinu
execmod
This access is seen on files, usually DSOs (shared libraries). Basically a DSO is loaded, at some point the application determines the code needs text relocation and uses the mprotect call to set the memory region read/write. After the text relocation, the code is marked back to read/exec which triggers the access check. Usually the DSO does not need to be text relocatable, but a programming mistake has happened. For further and probably a much more correct explanation of text relocation, look in section 2 of http://people.redhat.com/~drepper/dsohow
Since this mistake is so prevalent we have added a file context textrel_shlib_t which marks DSOs as allowing this privilege. So if you get an execmod on a library, you should report this as a bug to the package maintainer or upstream. And if you really want the application to run, mark the DSO as textrel_shlib_t.
chcon -t textrel_shlib_t PATHTOSHAREDLIBRARY
If you want to survive a relabel you can modify the local file context to label this file
semanage fcontext -a -t textrel_shlib_t PATHTOSHAREDLIBRARY
If you feel this should be in the default policy should also submit a bug on the selinux-policy package.
You can also find libraries that require execmod priv by executing
readelf -d PROGRAMS | fgrep TEXTREL
execstack
We have found a few programs that had the execstack flag turned on, but have been able to fix everyone of these fairly easily.
Ulrich says it all:
"As the name suggests, this error is raised if a program tries to make its stack (or parts thereof) executable with an mprotect call. This should never, ever be necessary. Stack memory is not executable on most OSes these days and this won't change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code."
Some libraries/applications are accidentally marked as requiring execstack. These usually happen because of a mistake in the build procedure. You can check if a library/application requires execstack by using the execstack utility.
execstack -q PATHTOPROGRAM
You can try to clean the flag and see if the application still runs.
execstack -c PATHTOPROGRAM
You should immediately report this as a bugzilla to the packager and/or the upstream maintainer to fix the code.
For a further discussion of execstack, you can look at section 4 of this security document, written by Ulrich.
http://people.redhat.com/drepper/nonsels
execheap
Ulrich says it all:
"The POSIX specification does not permit it, but the Linux implementation of mprotect allows changing the access protection of memory on the heap (e.g., allocated using malloc). This error indicates that heap memory was supposed to be made executable. Doing this is really a bad idea. If anonymous, executable memory is needed it should be allocated using mmap which is the only portable mechanism."
I have not seen a single bugzilla on execheap, so I would guess that most of Fedora code is clean.
execmem
There might be some reasonable uses for execmem, but Ulrich describes how programs could program in a safer manner to not require this access. Again if you find an application requiring this priv you should report it immediately to the upstream maintainers and to the selinux-policy. Since there is no way to get around this one other than setting allow_execstack to on.
Conclusion
Most of the problems that arose in FC5 being released were caused by the allow_execmod check being turned off. Turns out hundreds of libraries on the system are built incorrectly. Of course when the application does not run correctly because a library like libflashplayer is denied execmod, the user sees it as SELinux broke his application. We have tried to mark all of the libraries that require this priv as we find them, and hopefully the upstream maintainers are taking action to cleanup there libraries. Hopefully the pain all of us have felt by turning up the protection on user space will allow us to have safer more secure systems.
On the other hand, I'm not sure that this is complete:
Problems like leaked file descriptors show the weakness in tools that automatically generate policy, since the default would be allow access to the leaked descriptors.
That's certainly true of many automatic policy generation tools. Others, like the FD Tracker in Polgen are capable of distinguishing inherited file descriptors from those freshly generated, and can have more nuanced and interesting defaults. They still can't generate policy in a vacuum. That's always going to need human review, because too much information about what the program's meant to do has been erased from the binary.
One way to combat the leaked-fd problem...
In the Makefile, do:
LDFLAGS += -Wl,--wrap,open,--wrap,fopen,--wrap,opendir,--wrap,socket,--wrap,pipe OBJECTS = foo.o wrappers.o $TARGET : $OBJECTS $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^And then in wrappers.c do:extern int __real_open(const char *path, int flags, ...); extern FILE *__real_fopen(const char *path, const char *mode); extern DIR *__real_opendir(const char *name); extern int __real_socket(int domain, int type, int protocol); extern int __real_pipe(int filedes[2]); int setFdCoe(int fd, int enable) { int rc; long flags = 0; rc = fcntl(fd, F_GETFD, &flags); if (rc < 0) return rc; if (enable) flags |= FD_CLOEXEC; else flags &= ~FD_CLOEXEC; rc = fcntl(fd, F_SETFD, flags); return rc; } int __wrap_open(const char *path, int flags, ...) { int fd, rc, mode = 0; long errnum; if (flags & O_CREAT) { va_list arg; va_start(arg, flags); mode = va_arg(arg, int); va_end(arg); } fd = __real_open(path, flags); if (fd < 0) return fd; rc = setFdCoe(fd, 1); if (rc < 0) { errnum = errno; close(fd); errno = errnum; return rc; } return fd; } FILE * __wrap_fopen(const char *path, const char *mode) { FILE *f; int rc; long errnum; f = __real_fopen(path, mode); if (!f) return f; rc = setFdCoe(fileno(f), 1); if (rc < 0) { errnum = errno; fclose(f); errno = errnum; return NULL; } return f; } DIR * __wrap_opendir(const char *name) { DIR *d; int rc; long errnum; d = __real_opendir(name); if (!d) return d; rc = setFdCoe(dirfd(d), 1); if (rc < 0) { errnum = errno; closedir(d); errno = errnum; return NULL; } return d; } int __wrap_socket(int domain, int type, int protocol) { int fd; int rc; int errnum; fd = __real_socket(domain, type, protocol); if (fd < 0) return fd; rc = setFdCoe(fd, 1); if (rc < 0) { errnum = errno; close(fd); errno = errnum; return rc; } return fd; } int __wrap_pipe(int filedes[2]) { int rc; int x; int fds[2]; rc = __real_pipe(fds); if (rc < 0) return rc; for (x = 0; x < 2; x++) { int status; int errnum; status = setFdCoe(fds[x], 1); if (status < 0) { errnum = errno; close(fds[0]); close(fds[1]); errno = errnum; return status; } } filedes[0] = fds[0]; filedes[1] = fds[1]; return rc; }Re: One way to combat the leaked-fd problem...
Re: One way to combat the leaked-fd problem...
Ubuntu: Harder Than It Should Be.
Keep up the great work....
I'm an old mainframer who worked on ACF2 and loved the granularity of security...
An Old geek
SELinux - enforcing mode - execmod error - any compiler options
typ msg=audit(1160574210.165:179): avc: denied { execmod } for pid=3902 comm="runappp" name="libmyutil.so.3.20.117" dev=dm-0 ino=1052666 scontext=root:system_r:unconfined_t:s0-s
type=AVC_PATH msg=audit(1160574210.165:179): path="/opt/myshare/libmyutil.so.3.20.117"
I was reading through the journal and used chcon to fix this problem. But is there a way to provide some compiler options and compile the code to fix this problem.
I would appreciate if you can provide some info on this.
Re: SELinux - enforcing mode - execmod error - any compiler options
http://people.redhat.com/~drepper/selin
Re: SELinux - enforcing mode - execmod error - any compiler options
and am using the compiler flag '-fPIC' for shared objects to fix this problem.
chekbazaasaaa
google.com budet ohuevat', ya otvechayu
HeLLO..
---------------------
muhabbet
korku
msn nickleri
msn nickleri
netlog