Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Using scripting languages to "macro" policy Date: Fri, 1 Sep 2006 11:30:43 -0500
The idea I put forward here is to create a set of base objects in Ruby, Python, or something of that ilk that can be extended and used to define policy in an organized, error-checking, and namespaced manner. Heres a quick little example:
class LogDir < FileType
class SomeProgam < Application
This expands to all the relevant TE & FC statements. 'executable' generates the someprogram_exec_t type and all needed type transitions and allows, 'allow_role' looks up types associated with the role and generates relevant allows and transitions. The 'allow' statement works pretty much as expected, except that the FLASK class File is an actual Ruby class, with the ability to filter on permission categories, etc. This system isn't meant to replace all the work thats gone in to existing policies, nor does it set out to be a policy language of its own like existing high-level lanaguage work, but I think it would make an interesting little project. Ideas, comments, suggestions, criticisms, etc. would be appreciated. Aleks Kissinger -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Lorenzo Hernández García-Hierro <lorenzohgh_at_tuxedo-es.org> subject: Re: Using scripting languages to "macro" policy Date: Fri, 1 Sep 2006 20:32:40 +0200
Ruby is great for text processing, hence it can be a good option to write policy-related tools, say, policy browsers, an IDE, etc. I'm working myself on such stuff but using it to define the policy itself, while "fun" as a prototype it turns to be non scalable at all. Why? Check out the Ruby VMs out there. It will lower the performance dramatically. Think about loading hundreds of objects on kernel land... it's just insane. As an exercise, initialize 200-300 instances of something else similar to an existing profile of the current refpolicy. Add all the properties (or accessors/attributes now that we are on Ruby coding), etc. Then calculate the size on memory and access times (ex. when reading, writing, sorting, etc).
You would have to translate everything for using a much lower level
instruction set.
Disclaimer: I'm a Ruby guy, so to speak. Now I rarely code something in other language, except C. A collaborative policy development tool might be in the works. If you are familiar with Rails and interested about it, drop me a line. Cheers. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: Using scripting languages to "macro" policy Date: Fri, 01 Sep 2006 14:43:34 -0400
What you're talking about is what I would call policy patterns. Policy patterns is one thing I plan on attacking once the role infrastructure has been completed, but on a smaller scale. Here are a couple patterns I made on the side: define(`manage_files_pattern',` allow $1 $2:dir rw_dir_perms; allow $1 $3:file manage_file_perms;') define(`stream_connect_pattern',` allow $1 $2:dir search_dir_perms; allow $1 $3:sock_file { getattr write }; allow $1 $4:unix_stream_socket connectto;') define(`send_audit_msgs_pattern',` allow $1 self:capability audit_write; allow $1 self:netlink_audit_socket { create_netlink_socket_perms nlmsg_relay };')
> The idea I put forward here is to create a set of base objects in I'm not sure that this is actually easier, in fact its confusing to me (what does :r and :w mean? just read and write?). It seems like an unnecessary abstraction, for example allow_role. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Erich Schubert <erich_at_debian.org> subject: Re: Using scripting languages to "macro" policy Date: Fri, 01 Sep 2006 21:02:31 +0200
It would be very good to have a policy language which does NOT embed
code.
best regards,
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_ Nothing prevents happiness like the memory of happiness. --- A. Gide //\ Trauet euren Träumen, denn das Tor der Ewigkeit ist darin verborgen. V_/_
-- subject: Re: Using scripting languages to "macro" policy Date: Fri, 1 Sep 2006 18:10:07 -0500
> Ruby is great for text processing, hence it can be a good option to I think this may be an overly-pessimistic view of the scalability. With the current prototype of the system I'm working on, a policy with about 2000 types and about 60000 AV directives takes a little over a minute to compile, generating a 38 MB policy.conf. This is pretty high overhead for an iterative developement process, but some tweaking and modularization of the compilation procedure could probably mitigate these problems. I'm not quite sure what you mean by objects in kernel land and 200-300 instances of refpolicy, but once the Ruby policy is compiled to FLASK, the hard work is done. Then it just remains to push it through checkpolicy.
> Just one more dep: Ruby. The base objects are distributed with the policy itself.
> Disclaimer: I'm a Ruby guy, so to speak. Now I rarely code something Sounds interesting. I've had some (mixed) Rails experiences. If you want to shoot me an email about this or point me somewhere with more information, I'd like that. Now, in response to Christopher:
> What you're talking about is what I would call policy patterns. Policy <snip> Yes, I took some inspiration for the Ruby arch. by the way refpolicy structures its abstractions into patterns.
> A good point. Here the semantics are less clear than they could be. The Ruby policy organizes permissions in a class into permission "categories". The existance of these is reflected in some of the existing macros like file_read_perms, etc. which expand to a list of permissions that are "read-like". The :r and :w filter on those categories. Or...you can spefify perms explicitly (the File.perms() call just returns an array of perms), or you can do some array ops to get the perm set you want. For example: allow self, self, (Policy::CLASSES-[Security]), '*' allow self, self, Security, (Security.perms-[:load_policy, :setenforce]) Determining which abstractions are and are not necessary is a hard task, so I'm not really married to any that I've mentioned. And Erics comments...
> Hi Aleks, I've had the use of tools in mind from the start. In fact, as it stands, you can load the policy up in an interactive, irb shell. From there, you can query relationships, alter the policy, and ask individual components to produce TE/FC output. For a more sophisticated tool to leverage this, it would simply need to include a Ruby interpreter.
> We went down the XML road a couple of years ago. Hopefully someone will have success at it, but what we found was that XML proved too verbose and time-intensive to parse of the volume of policy in what was available at the time ("strict"). Again, thanks for all your comments. If any of you are not too discouraged yet and would like to contribute (or at least see some of it in action) let me know. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |