1

Question

(a) Is there? and if so (b) what is a standard or accepted way for MAC systems to deal with complex software and in particular with Python, Bash and other interpreters? (in terms of creating rules for this kind of "complex" and "versatile" software)

With python for example, it appears to me to be impractical to regulate the access the python process receives on the basis of the executables (which will always be the python executables etc). It at best would rather be regulated according to the trustworthyness of the "python-script" code involved (as this also defined the resources needed).

Background

  • Referring to MAC (mandatory access controll) here is meant to give reference to certain software like SELinux, grsecurity, TOMOYO, Apparmor and alike. (I am still struggling with the right term to reference to those concepts and software, which is why I express it here, trying to avoid ambiguity.)

  • The MAC is conceived here to be a tool/way to enhance security that goes in some way beyond things possible with discretionary access control (DAC).

  • This "additional security value" is caused by controlling the access in a more detailed manner than it might be possible with the DAC. As an example the access which a software receives may be based on more than just the USER its process is started with. And of course the files and resources that can be touched by a certain process is at best fine-tailored to the bare limit the programm actually needs.

  • It can be seen as a key goal of a MAC to limit the access to the minimum necessary.

  • If limiting (for security concerns) the access of a programm to those resources that it actually only needs is something which is wanted from a MAC system, than this seems most easy/practical for software which has a very limited functionality. Likewise more versatile and complex software seems by very far be much harder to be confined and limited.

Improve this question
6
  • 2
    I'm struggling to work out what you're looking for. Are you trying to implement some sort of protection mechanism to prevent scripts from accessing various stuff?
    – Polynomial
    Commented Dec 19, 2012 at 8:57
  • @Polynomial: thank you for your comment and your time. I am trying to understand better how sensible or "good"(meaning working, effective) rules in the MACs could be setup. Restricting a JPEG-viewer programme seems easy (because its so simple what resources it will need). That brought me to the simple reasoning that "what about python?". Python by design it should be powerful (because it might be more than a JPEG-viewer). The MAC rules there should be according to the task aswell, only the things are less clear there. You are also right: I would like to prevent scripts from accessing stuff!
    – humanityANDpeace
    Commented Dec 19, 2012 at 9:57
  • I understand that, but what are you trying to do? I can't work out whether you're looking for a way to implement these MAC rules in a particular tool, or if you're looking for some platform-specific mechanisms / APIs to do this, or what.
    – Polynomial
    Commented Dec 19, 2012 at 10:04
  • To be more clear. I am not developing a protection mechanism. Rather I was looking for one that already implemented. serverfault.com/questions/290828/… shows that some sort of solution sounds like not being the most straightforward appraoch :(
    – humanityANDpeace
    Commented Dec 19, 2012 at 10:06
  • 1
    Yeah, there's no way to do that. It's a Turing-complete language, so you can't detect what it's going to want to access ahead of time. You need to configure it or have the script writer provide some metadata.
    – Polynomial
    Commented Dec 19, 2012 at 10:22

2 Answers 2

Reset to default
1

For Turing-complete languages, you can't detect what they're going to do or access ahead of time. You can try to detect certain things based on usage of various language-specific framework classes and keywords, but it's not easy.

Let's say you're trying to stop someone from calling alert() in Javascript. Consider the following:

exec(
  atob('dmFyIHQ9MSx4PTA7eD1NYXRoLmxvZyh0KTsgaWYoeDwxKXthbD9ydCgnZGVycCcpO30=')
    .replace(/\?/g,'t')
);

Can you really write something that always identifies alert calls? Nope!

The only way to achieve this is to provide the control at a low level, e.g. within alert() itself. Obviously this isn't ideal; can you hook every possible JavaScript engine in every browser? Again, no. So you have to go lower still - maybe hook all calls to the system API used to create new windows. Oh, but now you need to be able to tell the difference between an alert() message and a normal window.

Not as easy as it first might seem, is it?

This is precisely why most mandatory access control systems focus entirely on access to resources, rather than operations. You have to know what you're trying to protect against in advance, and you have to know how that resource is going to be accessed. As such, there's no generic way to do what you want, even on a specific language. You need to manually configure the restrictions ahead of time.

Improve this answer
4
  • I very much appreciate your insight. Your example is impressive and surely an example how to hide stuff in code. The often so quickly said "its open source, no backdoors" is questioned by obfuscation like this. I am glad to have received this answer, thank you. Just like in serverfault.com/questions/290828/ there is the question if there is a chance to generate categories for arbitrary code, so that there can be functionality and a certain degree of security obtained?
    – humanityANDpeace
    Commented Dec 19, 2012 at 13:18
  • Again, there's no real way to automatically identify the purpose of some code, so you can't categorise it. The best you can do is have the script writer request certain permissions, and then have a human review and grant / reject them. This is exactly how Android apps work - the app is sandboxed and all code runs through the JVM, which has access controls built into its framework.
    – Polynomial
    Commented Dec 19, 2012 at 13:23
  • 100% correct. No argument about this. It is rather the mechanics I wonder. Let's call a binary XYZ a program - maybe a static one or not - we write a rule in the MAC to limit it. Let's call a .py script also a program, we could proceed the same way, but and that might be a major doubt. The rule refernce point is the executable (which in this case would be the python interpreter) and not the program which would be pyhton+(the script). Maybe the question rephrased would be how the content can be part of a the MAC system rules? Happy for your input. Sorry I can so badly phrase stuff
    – humanityANDpeace
    Commented Dec 19, 2012 at 13:34
  • Not sure I understand. Once you're doing MAC at the system level there's no difference between a native executable and a bash script. You just have to launch the script interpreter executable with a particular set of MAC rules (a context) that applies to the script.
    – Polynomial
    Commented Dec 19, 2012 at 13:50
0

You need to restrict not python at whole but particular python script. (For example /usr/bin/rdiff-backup). AFAIK, Smack and TOMOYO (and CaitSith) support this approach. So they threat script launched directly (thus, it should have #!/usr/bin/python as first line and +x perms) as having own domain (in TOMOYO) or owning security labels attached to the script file itself (Smack).

Plus, TOMOYO supports manual domain transfer - this is useful for things like Apache (with mod_tomoyo). Script (if allowed) can 'manually' switch to another security domain, when accessing, for example, data of particular user.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .