Rui Miguel Silva Seabra wrote:
> Hi,
>
> On Mon, Sep 24, 2007 at 04:31:22PM +0100, Brian Candler wrote:
>> On Sun, Sep 23, 2007 at 10:54:06PM +0100, Rui Miguel Silva Seabra wrote:
>> > On Sat, Sep 22, 2007 at 06:47:46PM -0500, L. V. Lammert wrote:
>> > > OBSD is UNIX, .. SELinux is Linux. If you want a secure, efficient,
>> > > compact OS done by folks you can trust and actually talk to, use OBSD; if
>> > > you want 'fairly secure Linux' [which has had thousands of hand in it
>> > > including NSA, as mentioned previousy], use OpenSUSE with ***AppArmor***.
>> > > Simple and easy to implement, even by less senior Admins.
>> >
>> > Can you say "root can only run this and that application when su'ed from
>> > that guy, and may not open any net connection, but open this file and none
>> > else" in OpenBSD? If so, how can I do it? :)
>>
>> You solve the problem a different way:
>>
>> - You don't give the guy root access, but their own userid
>
> The guy can be some stupid binary software with an "if(uid!=root) bail();"
People running arbitrary binary software requiring root on their systems
deserve what they get. You can not work around this stupidity by ANY policy.
>> - You set file permissions so this userid can read only the file of interest
>
> "none else" => find / -type f -exec chmod o-r \{\} \; is a lot of overkill....
You do not to do it everywhere, just protect what is needed (logs, data
whatever)
Most daemons in OpenBSD run isolated (chroot) in their own space without
access
to anything at all, without resorting to magic solutions, and any additional
work on the part of the administrator.
>> - You use pf rules so that this user ID cannot send network packets
>>
>> - If this guy needs root for something (e.g. to bind to port 80), then you
>> write a three-line setuid root wrapper which binds to port 80 for them.
>> If you have a lot of this to do, then consider an 'open server' which
>> returns the open file descriptor.
>
> All in all, forms of doing it all, but doing all you described creates a lot
> more work than creating an SELinux policy :)
We have also systrace, which allows to create SELinux like policies.
Disregard its vulnerabilities for a moment and think about it.
What happened? (even before the vulnerabilities were announced)
Nobody used it.
No general/global repository of policies survived.
Few security tools attempted to use it.
It's only good use so far is in the ports tree, making sure
that port authors can be sure that programs did not access unwanted parts of
the filesystem. This is not a security use. It is useful as tool to help
for porters.
Why?
Every system and setup is unique. You can not define 'tight' policies and
expect them to be valid in other systems.
If you are an experienced systems administrator, you can make anything work.
Knowing the limitations and vulnerabilities, you can put systrace, to
good use as an extra line of defense.
But such complex mechanisms rarely aid the overall security.
It creates a "false sense of security" (tm)
Few take full advantage of it.
The rest are either turned off or misconfigured.
Most wrongly believe that they are magically protected.
Look at Windows. It has some advanced filesystem permissions stuff,
with elaborate rights, inheritance, bells and whistles.
Is it used correctly? No.
Is it easily auditable? No.
Can you easily tighten default permissions without breaking lots of
stuff? Very unlikely.
You come accross all kinds of programs using it incorrectly and create a
whole bunch of security problems.
It does make good marketing material though.
In security, complex != good.
Can
--
In theory, there is no difference between theory and practice.
But, in practice, there is.
