On 10/19/2013 09:32 AM, Dominick Grift wrote:
On Fri, 2013-10-18 at 22:02 +0200, Dominick Grift wrote:
On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
I pushed an update of CIL to bitbucket.
I had to do this, to make it compile ( not sure what i might have broken
by doing this ):
--- a/src/cil.c
+++ b/src/cil.c
@@ -1493,7 +1493,6 @@ void cil_userbounds_init(struct cil_userbounds
**userbounds)
*userbounds = cil_malloc(sizeof(**userbounds));
(*userbounds)->user_str = NULL;
- (*userbounds)->user = NULL;
(*userbounds)->bounds_str = NULL;
}
Also a thing i noticed, which is unrelated to secilc, but related to
cilpolicy is that object_r role is associated to identities.
The object_r string is not really a role, although it looks like it.
Its just a string that is used as a place holder for the role security
attribute of objects.
Anyhow, i am going to write a minimum policy with secilc tomorrow i
think, so maybe then i will find new bugs, insights.
Thanks for your work
Been playing with this today and so far so good except for a few things:
Not sure if its due to my incompetence or due to the line i removed
( see above) from cil.c, login programs (pam) is not able to get a valid
context for my users. I believe i set all the associations up properly
Sounds like you've figure out this problem.
I noticed that no matter if you just want to create a default policy
model, you always have to take the option security models (MLS/MCS) into
account at least to some degree. For example you need to specify current
and clearance with filecon even if you wish to not use use MLS/MCS
We want to avoid optional arguments to and CIL statements. Because of
this, the mls/mcs arguments are required, even when building non-mls/mcs
policies.
Another thing i noticed which is loosely related is that if you build a
mcs policy, and install it, then run restorecon -R -v -F, it will reset
contexts using current and clearance (it has s0-s0 specified in
file_contexts) no matter how many times you run it. It will always reset
from s0 to s0-s0
This should be easy enough to fix. If the low and high levels are the
same, then we'll just output the low.
As said above already, i now also encountered the object_r issue myself:
it sucks. One needs to allow object_r role access to all types...
object_r is not even a role (or atleast it should not be AFAIK)
True, but this actually isn't going to be bad. The majority of types are
going to be associated with an attribute, and usually through a macro, e.g.:
(type foo_t)
(call files_type (foo_t))
Either the files_type macro could perform the object_r association:
(macro files_type ((type t))
(typeattributeset file_type t)
(roletype object_r t))
or you could just associate object_r with the attribute somewhere else:
(roletype object_r (file_type))
Lastly i have to get used to the cil syntax, The documentation is a bit
inaccurate. For example it seems that typeattributetypes was renamed to
typeattributeset.
Yes, the documentation is lacking right now. There are still ongoing
discussions on changes to the CIL syntax. As things settle down, we
should be able to put some focus towards improving the documentation.
Right now, the best source is probably Jim's cilpolicy.git repo.
I was trying to associate 3 types to a single type attribute and i first
encountered typeattribute set, and the example showed how its supposed
to be used with "and or xor not", and so i tried that, but it turned out
you can only associate two types to a type attribute using any of those
keywords
I believe you can associate more than one type via the following:
(typeattributeset attr (type1 type2 type3))
But, typeattributeset is one of the syntax changes we are discussing. As
you mentioned, you can only associate two types to a type attribute
using expressions. This is going to change. Of course it requires adding
more parenthesis, but we already have a ton of those, so what's one more
set.
Later on i stumbled upon typeattributetypes, and the examples looked
promissing. it mentioned that you can use it to associate more types to
the attribute with it. But when i tried it, it turned out it no longer
existed.
Yes, we replaced typeattributetypes with typeattributeset.
However, i tied the strings together and managed to associate 3 types to
a single type attribute using the typeattributetypes example with the
typeattributeset statement.
Also i was not able to write TE AV rules with two target types. e.g.
where we previously used brace expansion: allow bla_t { foo_t
bar_t }:file read;
Yes, the source/target parameters of the allow rule only allow a single
type or typeattribute. CIL is not meant to be succinct. You'll find
there's a great deal of repetition. The idea is that higher level
languages would allow for succinctness.
I tried several things like: (allow (bla_t ( foo_t bar_t))
all_file_perms), but no go
If you really don't want two allow rules, you can create a typeattribute:
(typeattribute foobar)
(typeattributeset foobar (foo_t bar_t))
(allow bla_t foobar all_file_perms)
But unless the foobar attribute has some kind of meaning, it probably
makes more sense to just have two allow rules.
It is just a matter of getting used to the new way of doing things, but
i feel that its very powerful, and i like it alot.
Also secilc seems nice and fast, especially if it also takes care of the
neverallow rules (doing that with semodule link/expand takes ages)
It does check neverallow rules.
So, yea, the only pressing issue now for me is to get my users to log
in. I have created a nice minimal policy today with cil and other than
this issue it works great!
Classes: 54 Permissions: 193
Sensitivities: 1 Categories: 1024
Types: 4 Attributes: 1
Users: 1 Roles: 2
Booleans: 0 Cond. Expr.: 0
Allow: 54 Neverallow: 0
Auditallow: 0 Dontaudit: 0
Type_trans: 0 Type_change: 0
Type_member: 0 Role allow: 0
Role_trans: 0 Range_trans: 0
Constraints: 0 Validatetrans: 0
Initial SIDs: 27 Fs_use: 23
Genfscon: 84 Portcon: 2
Netifcon: 0 Nodecon: 0
Permissives: 0 Polcap: 2
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
