Hi, I've subscribed to this list just to post this one question.
The inkscape binary is marked with PT_GNU_STACK RWE. This creates problems for the SELinux strict policy, and requires that special privileges be granted for inkscape as a "legacy domain".
The question is, does inkscape really require an executable stack?
I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overridden with ld -z noexecstack.
It would be a lot easier to write the inkscape security policy if it didn't require executable stack.
On Tue, 22 Feb 2005 21:43:21 -0500, Ivan Gyurdiev wrote:
The inkscape binary is marked with PT_GNU_STACK RWE. This creates problems for the SELinux strict policy, and requires that special privileges be granted for inkscape as a "legacy domain".
Interesting, I thought SELinux was orthogonal to the execstack stuff.
The question is, does inkscape really require an executable stack?
Almost certainly the answer is no.
I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overridden with ld -z noexecstack.
What version of GCC are you using? AFAIK assembly has not triggered PT_GNU_STACK generation for a while now but you'd have to check with Ingo Molnar. I'm not sure it's wise to override GCCs heuristics though.
It would be a lot easier to write the inkscape security policy if it didn't require executable stack.
Can't you just tell SELinux not to care about executable stacks? You can still restrict read/writes. Though given that Inkscape has to be able to save files pretty much anywhere I'm not sure how much you can really lock it down.
thanks -mike
On Wed, 2005-02-23 at 10:06 +0000, Mike Hearn wrote:
On Tue, 22 Feb 2005 21:43:21 -0500, Ivan Gyurdiev wrote:
The inkscape binary is marked with PT_GNU_STACK RWE. This creates problems for the SELinux strict policy, and requires that special privileges be granted for inkscape as a "legacy domain".
Interesting, I thought SELinux was orthogonal to the execstack stuff.
I'm not familiar with all the details - it has to do with the way linking works, I think. It triggers execmem and execmod denials described here: http://www.nsa.gov/selinux/list-archive/0412/9720.cfm
Also, the kernel translates PROT_READ to PROT_READ | PROT_EXECUTE in mmap and mprotect if PT_GNU_STACK is missing, or is RWE. The SElinux people are writing a patch to address this issue separately, but the proposed solution so far further reduces the security of the system.
The question is, does inkscape really require an executable stack?
Almost certainly the answer is no.
Can it be corrected, then?
I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overridden with ld -z noexecstack.
What version of GCC are you using? AFAIK assembly has not triggered PT_GNU_STACK generation for a while now but you'd have to check with Ingo Molnar. I'm not sure it's wise to override GCCs heuristics though.
Well, I wouldn't know why exactly it gets marked RWE, but that's what happens. This is gcc-3.4.3-19
It would be a lot easier to write the inkscape security policy if it didn't require executable stack.
Can't you just tell SELinux not to care about executable stacks? You can still restrict read/writes.
Well, I think the idea of SELinux is to not give programs privileges they don't actually need.
Though given that Inkscape has to be able to save files pretty much anywhere I'm not sure how much you can really lock it down.
Yes, all of those issues can be worked around in the policy, but that makes the policy less secure. The case of inkscape would require writing a brand new policy for inkscape to place it in its own domain. That's because right now it runs in a "generic" user_t domain, which is used for all programs without their own policy. I don't think the SELinux people will agree to a workaround that applies to every other program in this domain.
In other words, yes, but it would be better if that wasn't necessary.
On Wed, 23 Feb 2005 06:22:11 -0500, Ivan Gyurdiev wrote:
Can it be corrected, then?
Maybe, but you need to find out why GCC is triggering PT_GNU_STACK generation. At various times GCC will generate trampolines on the stack, the Ada compiler does this in particular so maybe these days g++ does too.
Once we understand why it's being generated, then it makes sense to talk about overriding it.
Well, I wouldn't know why exactly it gets marked RWE, but that's what happens. This is gcc-3.4.3-19
Unless it was changed yet again, this version should not put the marker in as soon as it sees inline assembly. So it may be some other issue.
You could start by figuring out which .o file causes it (using objdump or something?) and then get G++ to spit out the assembly it's producing and look at that. Or just try disabling all the MMX in the build and see if it affects it.
thanks -mike
You could start by figuring out which .o file causes it (using objdump or something?) and then get G++ to spit out the assembly it's producing and look at that. Or just try disabling all the MMX in the build and see if it affects it.
I'm not quite sure how to use objdump to find it, but --disable-mmx does get rid of it.
Ivan Gyurdiev wrote:
You could start by figuring out which .o file causes it (using objdump or something?) and then get G++ to spit out the assembly it's producing and look at that. Or just try disabling all the MMX in the build and see if it affects it.
I'm not quite sure how to use objdump to find it, but --disable-mmx does get rid of it.
Well, /src/libnr does have some assembly code for mmx.
Bob
On Thu, 2005-02-24 at 13:46 +0000, Mike Hearn wrote:
Ivan Gyurdiev wrote:
I'm not quite sure how to use objdump to find it, but --disable-mmx does get rid of it.
Talk to Ingo Molnar, last time I discussed this with him he said assembly should no longer cause that. I guess it's more complex than I thought.
Ingo, perhaps you can clarify any confusion here as to when PT_GNU_STACK RWE is generated.
We're trying to remove the executable stack requirement from the inkscape binary (and mplayer, lame, gpg, and Sun's JRE for that matter). It causes problems for the SElinux strict policy due to the kernel's READ implies EXECUTE logic.
On Wed, 23 Feb 2005 06:22:11 -0500, Ivan Gyurdiev wrote:
That's because right now it runs in a "generic" user_t domain, which is used for all programs without their own policy. I don't think the SELinux people will agree to a workaround that applies to every other program in this domain.
Incidentally, am I the only one who thinks it's stupid for SELinux to be developing policy for random desktop applications upstream? I've raised this with the Fedora SELinux guys before - that approach can never work reliably.
You guys really need to nail stable binary distribution of policy *first*, and then write decent documentation so the people actually working on Inkscape can write and maintain policy. Otherwise the moment a new version comes out it'll require some random permission it the policy doesn't allow, and break in mysterious and subtle ways.
thanks -mike
On Wed, 2005-02-23 at 13:38 +0000, Mike Hearn wrote:
On Wed, 23 Feb 2005 06:22:11 -0500, Ivan Gyurdiev wrote:
That's because right now it runs in a "generic" user_t domain, which is used for all programs without their own policy. I don't think the SELinux people will agree to a workaround that applies to every other program in this domain.
Incidentally, am I the only one who thinks it's stupid for SELinux to be developing policy for random desktop applications upstream? I've raised this with the Fedora SELinux guys before - that approach can never work reliably.
I can't comment on that - I'm just a novice contributor and I'm trying to help with what I can. I believe they do this so that security issues are centralized in one place. I'm not sure how mandatory the mandatory access control becomes otherwise. From a practical standpoint I can tell you that writing this thing is not completely trivial, so it helps if people have some experience writing other policies.
You guys really need to nail stable binary distribution of policy *first*, and then write decent documentation so the people actually working on Inkscape can write and maintain policy. Otherwise the moment a new version comes out it'll require some random permission it the policy doesn't allow, and break in mysterious and subtle ways.
That's a good point - perhaps you should discuss it on the NSA list.
That does not apply to inkscape, however, since as I've mentioned inkscape runs in the generic user_t domain, which provides basic permissions to most desktop apps. If inkscape was changed to do something specialized that didn't apply to user_t (like require RWE stack permissions), I suppose it would need its own policy.
On Wed, 2005-02-23 at 08:56 -0500, Ivan Gyurdiev wrote:
I can't comment on that - I'm just a novice contributor and I'm trying to help with what I can. I believe they do this so that security issues are centralized in one place. I'm not sure how mandatory the mandatory access control becomes otherwise. From a practical standpoint I can tell you that writing this thing is not completely trivial, so it helps if people have some experience writing other policies.
Yes, that is what I was told before. Centralising policy lets you perform a better analysis of it, is that right?
I'm not really convinced ... you could apply that logic to any facet of software development. By all means have central groupings of experts to go for *review* of policy, but actually writing it and maintaining it downstream seems like a losing proposition (it won't always reflect the latest version of the software correctly).
That's a good point - perhaps you should discuss it on the NSA list.
That does not apply to inkscape, however, since as I've mentioned inkscape runs in the generic user_t domain, which provides basic permissions to most desktop apps. If inkscape was changed to do something specialized that didn't apply to user_t (like require RWE stack permissions), I suppose it would need its own policy.
Alright, fair enough. So you're not actually writing policy specifically for Inkscape? If this is just the result of testing various applications to see how they run in user_t then you have my apologies, I misunderstood what you are trying to do.
thanks -mike
Quoting Mike Hearn <mike@...333...>:
Yes, that is what I was told before. Centralising policy lets you perform a better analysis of it, is that right?
I'm not really convinced ... you could apply that logic to any facet of software development. By all means have central groupings of experts to go for *review* of policy, but actually writing it and maintaining it downstream seems like a losing proposition (it won't always reflect the latest version of the software correctly).
I think the difference is that at this point in time, designing and writing selinux policies is new to everybody. This is bleeding-edge stuff, where best practices and broadly applicable conventions are only beginning to evolve. Most upstream projects aren't going to have people with the requisite background.
Under those circumstances I think it does make some sense to concentrate the knowledge in one place, where everyone can easily share experience.
In the long-term, yes, I think it would eventually make sense to push the task to upstream maintainers, at least in large part. But the knowledge infrastructure just isn't there yet.
For a historical parallel, look at the way packing for various distribtions has evolved. These days most projects provide their own .spec files and debian/ directories (which distributions often use as a basis, even if they don't use them directly), but it was not always so...
-mental
On Wed, 2005-02-23 at 15:16 -0500, mental@...3... wrote:
Under those circumstances I think it does make some sense to concentrate the knowledge in one place, where everyone can easily share experience.
OK, that makes sense. And I think some policy is better than no policy at all, at least that way it'll get debugged :)
In the long-term, yes, I think it would eventually make sense to push the task to upstream maintainers, at least in large part. But the knowledge infrastructure just isn't there yet.
Yep. Some tutorials on writing policy for desktop software would be nice. Right now all I can find is oriented towards servers (which is fair enough ...)
participants (5)
-
unknown＠example.com -
Bob Jamison -
Ivan Gyurdiev -
MenTaLguY -
Mike Hearn