On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 13:32:05, [email protected] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
> On Jun 09, 2007, at 12:46:40, [email protected] wrote:
> > 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.
isn't this just the flip side of the same problem?
every time you define a new attribute you need to go through all the files
and decide if the new attribute needs to be given to that file.
No you don't, you can add attributes to a type after-the-fact. In concept
this problem is very similar to programming: You have various documented
interfaces used by different policy files to interact with each other. As
long as your policy files conform to the documented interfaces then you
*DONT* have to manually inspect each file because you can make basic
assumptions. On the other hand, when you break that interface "contract" you
will get very unexpected results. For the above example:
My syslog policy file would create a "logfile" attribute and types for
"/var/log/auth/auth.log", "/var/log/kern/kern.log", and "/var/log/messages".
It would also create a "logdaemon" attribute which has automatic type
transitions to create files in different "/var/log/*" directories Finally,
it would allow the syslogd type to create and append to its specific file
types for "auth.log", "kern.log", and "messages".
My logrotate policy file would depend on the syslog policy and would declare
the logrotate daemon type as a "logdaemon", and additionally allow logrotate
to read, rename, append, and delete "logfile" types. Since logrotate is a
"logdaemon", it already has the appropriate type transitions for new types.
My samba policy file would depend on the syslog policy and would declare the
samba daemon type as a "logdaemon" and the "/var/log/samba/*" type as a
"logfile". Then it would add a type transition rule so when "logdaemon"
creates new files in "samba_log_dir_t", they have the appropriate
"samba_log_t" label. Finally, samba would allow itself to append to
"samba_log_t" files.
if you have your policy figured out and then go and apply it to
applications then you are correct.
I'm talking about the situation where you start off by defining a policy
for Samba, and then afterwords decide that you want to have seperate
"logfile" and "logdaemon" type then you would need to go back and
re-examine all the files to tell what needs to be labeled as what.
if you can do all the policy design in advance (and get it right) then
SELinux is a great solution. if you don't have that time and have to do
the policy incrementaly you will end up revisiting and revising your
entire policy each time you go to add something.
Note that now when "logrotate" runs and rotates files in /var/log/samba, it
will automatically create the new files with type "samba_log_t", even though
there are no *direct* associations between those types. If the syslog policy
file was poorly written it could seriously adversely affect the security of
the system, but hopefully that's obvious :-D. Policy development is _hard_,
it's a whole separate state-machine and pseudo-programming-language that
should mostly be left to security professionals or very experienced
developers/sysadmins.
I _am_ a security professional. I've been doing security sysadmin work on
Linux for over a decade now. From your description I'm exactly the type of
person you are saying should be figuring this out. So please back off of
the 'this is hard, you should leave it to the professionals' line a
little bit ;-)
if the AA policies can be compiled into SELinux policies that would work
(currently they can't and many SELinux people oppose the features that
would need to be added to make it possible) but the compile process leaves
room for more bugs in an areas that's going to be hard to investigate.
(This isn't a fault of SELinux, it's a common issue with compilers, the
compiled 'thing' is designed to be machine friendly, not user friendly. it
doesn't matte if it's compiling C into machine code or high-level firewall
rules into iptables commands or AA policies into SELinux labels and
policies). adding a complex intermediate layer does not nessasarily add
security, but it definantly adds complication.
once SELinux has a way for a trusted user to edit a security sensitive
file (via the process of creating a file and renameing it into place)
without needing SELinux aware tools and have the result accepted as valid
by the rest of the system then it becomes possible to implement an AA to
SELinux policy compiler, but saying that AA should not be accepted becouse
it's possible to modify SELinux and write such a compile with sufficant
effort is not reasonable. While there are many cases where multiple ways
of doing something are not allowed into the kernel (suspend/hibernate is
an example) there are also cases where multiple ways of doing things are
allowed, and the LSM hooks are in place explicitly to permit different
types of security modules to use them.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [AppArmor 00/45] AppArmor security module overview
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
- Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
