On Mon, Aug 24 2009, andrew mcelroy wrote:
>> >
>> >> On Sun, Aug 23, 2009 at 11:28 PM, Manoj Srivastava <[email protected]
>> >wrote:
>> >>
>> >>>
>> >>> On Sun, Aug 23 2009, andrew mcelroy wrote:
>> >>>
>>
>> >>> The obvious solution appears to be mandatory, role based access
>> >>> controls, SELinux would do everything you want. chroots are not
>> really
>> >>> meant for security; and virtual machines are overkill.
>>
>> > manoj
>>
>
> If chroots aren't for security, then what are they for?
Some discretionary separation of diskspace, and mostly a mild
deterrent. If anyone can get root access inside the chroot, you are
toast. Certain applications _require_ root access, especially during
initialization; so a buggy application, and you might as well not have
a chroot. And chroots do not control network access at all. And
processes in a chroot can interfere with any other process on the
system (a bad thing) -- and can also communicate with them (which might
be a good thing -- see below).
See also: http://lwn.net/Articles/252794/ (I agree with the
article, not so much with some of the comments).
> I have reread that statement several times, and it still confounds me.
> Would you consider SELinux more secure (generally speaking) than BSD Jails?
There is not contest. Jails are discretionary, they do not have
MAC, or policy driven security that can be tested via information flow
analysis, and essentially provide zilch information assurance. SELinux
is deny be default, root is not god, even in the sandbox, applications
running as root can still be restricted by the kernel (very limited
root). By contrast, jails offer the same old coarse grained,
discretionary access controls inside the jail.
No software change is needed in the application -- you can run
any new application on a SELinux box, with no futzing around with init
script to place the app in a jail
BSD jails do overcome some of the failures of chroot, and do
make it harder to escape the jail. But they offer little protection
inside the jail. There is only one IP address per jail, and no loopback
device. There are no device nodes. Some applications won't run under
these conditions.
With SELinux, you can control IPC; with bsd jails either your
process cannot communicate with the other process (not in same jail)
or you have no protection between processes (in same jail).
Now, I have not been keeping up with trustedBSD, but that had
real promise. That actually has the promise of being as broad in scope
as SELinux, and just as non-bypassable.
Also, http://en.wikipedia.org/wiki/SELinux has a decent writeup,
apart from their failure to note the epic fail of apparmor because
they use path based security (but that is the subject of another
thread).
http://www.ibm.com/developerworks/linux/library/l-selinux/
manoj
Oh, these are my opinions, and you may well not actually share them. I
also am too busy at the moment to participate in a juicy flamewar, so
please keep this in mind.
--
We are all in the gutter, but some of us are looking at the stars. Oscar
Wilde
Manoj Srivastava <[email protected]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"NLUG" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nlug-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
