Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
From: Kyle Moffett
Date: Sat Jun 09 2007 - 13:06:21 EST
On Jun 09, 2007, at 12:46:40, david@xxxxxxx wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
Typical "targetted" policies leave all user logins as
unrestricted, adding security for daemons but not getting in the
way of users who would otherwise turn SELinux off. On the other
hand, a targeted policy has a "trusted" type for user logins which
is explicitly allowed access to everything.
Ok, it sounds as if I did misunderstand SELinux. I thought that by
labeling the individual files you couldn't do the 'only restrict
apache' type of thing.
That said, if you actually want your system to *work* with any
default-deny policy then you have to describe EVERYTHING anyways.
How exactly do you expect AppArmor to "work" if you don't allow
users to run "/bin/passwd", for example.
for AA you don't try to define permissions for every executable,
and ones that you don't define policy are unrestricted.
so as I understand this with SELinux you will have lots of labels
around your system (more as you lock down the system more) you need
to define policy so that your unrestricted users must have access
to every label, and every time you create a new label you need to
go back to all your policies to see if the new label needs to be
allowed from that policy
Actually, it's easier than that. There are type attributes which may
be assigned to an arbitrary set of types, and each "type" field in an
access rule may use either a type or an attribute. So you don't
actually need to modify existing rules when adding new types, you
just add the appropriate existing attributes to your new type. For
example, you could set up a "logfile" attribute which allows
logrotate to archive old versions and allows audit-admin users to
modify/delete them, then whenever you need to add a new logfile you
just declare the "my_foo_log_t" type to have the "logfile" attribute.
On the other hand, I seem to recall that typical "targeted" policies
don't grant most of the additional access via access rules, they
instead add a special case to the fundamental "constraints" in the
policy (IE: If the subject type has the "trusted" attribute then skip
some of the other type-based checks).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/