On Tue, 24 Jul 2007, Stephen John Smoogen wrote:

> On 7/24/07, John Logsdon <[log in to unmask]> wrote:
>> A number of people - not on this list - have objections to SEL, even including
>> the suggestion that it is really a business model to sell support rather than
>> offer security!
>>
>> Mine has always been that a security system that depends on various utilities
>> must be fundamentally insecure as anyone can insert corrupted versions and a
>> hacker can alter the path so that the unsuspecting user ends up copying their
>> files out as well as doing an ls for example.  And if you happen to disable
>> SEL then enable it again, you have I believe to rebuild the filestore.
>>
>> Others view the LSM as insecure by virtue of exported symbols.
>>
>
> I don't know where people have come up with the above, but I have
> heard a lot of it before. Most of it has been refuted or shown to be
> wrong (the risk of a bad binary is the same in grsecurity and selinux.
> Both read their policies from a 'blob' into the kernel and figure out
> what to do then.)
>
>> A lot can be done with standard access controls and it is a great pity that so
>> many packages are wrapped up and thus installed with world permissions, read
>> permissions when not appropriate and other loopholes.  It would be far too
>> much to expect Connie and Troy (or our friends at CentOS) to reset all of
>> these - it is really a hole created by the UV maybe to justify the inclusion
>> of SEL.  Proper setting of home directories that mirrors group  access can
>> reduce visibility. (ie set the home as /home/groupname/username with 2771
>> group permissions, group membership for user and  0700 for the home
>> directory) controls a lot of things.
>>
>
> I think you will need to provide specific examples. I do not know of
> many files in a default install that are set to being world writable
>
>
>> I always disable SEL and use grsecurity (www.grsecurity.net) which is a kernel
>> patch that requires no supporting utilities other than the gradm control
>> utility.  It includes the PaX patches.
>>
>> The only issue then is that the grsec patches generally refer to the latest -
>> or nearly latest - kernels and there is some debate that a stable version
>> should be made available for 'stable' kernels such as used by the Upstream
>> Vendor.
>>
>
> I thought the grsecurity people did that, but it was on a contract
> basis (e.g. their sales model as it is both hard and expensive to
> support older kernels for any length of time).
>
>
>> Policies are always a problem to set of course.
>>
>> Thanks for everything.
>>
>> On Tuesday 24 July 2007 06:21:47 Keith Lofstrom wrote:
>>> On Mon, Jul 23, 2007 at 04:38:49PM -0700, Zhi-Wei Lu wrote:
>>>> ...
>>>> Many times, one does not think that it is an SELinux related issue
>>>> and waste a lot of energy trying to debug the problem. I am just
>>>> wondering how people are coping with SELinux: love it, hate it,
>>>> disable it, disable some transactions.  I would really like to hear
>>>> the words of wisdom on this topic.
>>>
>>> I, too, am worried about SELINUX.  I would work with it more, but
>>> there seems to be little accurate information about configuring it
>>> for new apps (such as OpenVPN).  I set it to permissive, and may turn
>>> it off entirely unless I can find better info about configuration
>>> with SL5.
>>>
>>> Local acquaintance Crispin Cowan developed AppArmor, now a part of
>>> Novell/SUSE.  Crispin makes a convincing ease-of-use case for the
>>> now-free-and-open AppArmor, and I might use that instead of SELINUX
>>> if the config files become available for SL5.  Crispin will be at
>>> OSCON this week, and I expect to see him a few times;  if anyone
>>> wants me to ask him more questions about AppArmor, I can.  AppArmor
>>> might prove an interesting alternative for the SL5 user community
>>> to develop and use as an add-on package.

How does AppArmor solve this security issue?

-Connie Sieh
>>>
>>> Keith
>>
>>
>>
>> --
>> Best wishes
>>
>> John
>>
>> John Logsdon                               "Try to make things as simple
>> Quantex Research Ltd, Manchester UK         as possible but not simpler"
>> [log in to unmask]              [log in to unmask]
>> +44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com
>>
>> -------------------------------------------------------
>>
>> --
>> Best wishes
>>
>> John
>>
>> John Logsdon                               "Try to make things as simple
>> Quantex Research Ltd, Manchester UK         as possible but not simpler"
>> [log in to unmask]              [log in to unmask]
>> +44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com
>>
>
>
>