• 1
Awesome post. Thanks!

That's a neat piece of visibility into some Fedora components I don't often see. Particularly, thanks for the link to Ulrich's notes.

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.

Planets don't have elliptical orbits any more than they have circular ones. Elliptical orbits are more useful tools for thinking about their orbits, not ultimate truth.

So are astronauts in the ISS’s circular orbit, so would they if they were in an elliptical orbit.

So only if they are in fairly circular orbits can they keep orbiting the magnet for a long time. Similarly one reason that the planets have fairly circular orbits is so that they dont crash into each other.

One way to combat the leaked-fd problem...

In nash, we now have open() and friends set to use close-on-exec by default. This still doesn't help with libraries we link against, but it is a step in the right direction. For those who want to know how, here's the gest of it.

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...

(You also want to declare setFdCoe() in a header someplace, so functions that do depend on open-on-exec can mark Fds explicitly. Or they can use fcntl for it, but this API is simpler. If you always use fcntl elsewhere, then you'll want to mark setFdCoe() "static")

Re: One way to combat the leaked-fd problem...

... And for those who want to copy paste, that Makefile should be:
LDFLAGS += -Wl,--wrap,open,--wrap,fopen,--wrap,opendir,--wrap,socket,--wrap,pipe
OBJECTS = foo.o wrappers.o
$TARGET : $OBJECTS
	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^
(man, putting a tab character in a web form is harder than it shouold be)

# Integrating Ubuntu with a Windows-based network is harder than it should be *for end-users* Posted by: Anonymous [ip: .

Hey, that's a great new motto:

Ubuntu: Harder Than It Should Be.

I'm glad to see the FC5 is closing al the holes. Perhaps we can get Fedora to be recognized as a very secure platform....

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

My code is basically compiled on RHEL 3 with gcc 3.2.3 and I am trying to run on RHEL 5. In the SELinux enforcing mode, when I run my app, I get this message in audit.log..

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-s0:c0.c255 tcontext=root:object_r:bin_t:s0 tclass=file
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

Did you look at the description here?

http://people.redhat.com/~drepper/selinux-mem.html

Re: SELinux - enforcing mode - execmod error - any compiler options

I looked into this - http://people.redhat.com/drepper/textrelocs.html.
and am using the compiler flag '-fPIC' for shared objects to fix this problem.

Org Proxy-Connection: close Linker error when using -qextchk option on AIX64 - Unix Forum Linker error when using -qextchk option on AIX64 This is a discussion on Linker error when using -qextchk option on AIX64 within the Aix forums, part of the Unix category; hi , i am trying to compile on AIX using -qextchk flag , but i am getting the below linker error.

bolindir.com (http://www.bolindir.com)

chekbazaasaaa

(Anonymous)
proverka bazy! proverka bazi
google.com budet ohuevat', ya otvechayu

  • 1
?

Log in