On Wed, 2004-10-27 at 14:10 -0400, Valdis.Kletnieks@private wrote:
> On Wed, 27 Oct 2004 13:56:03 EDT, Colin Walters said:
>
> > You can quite easily express "don't allow program to follow untrusted
> > symlink" in SELinux by simply not granting it { read } permission for
> > <target>:lnk_file.
>
> Good. Now tell me how to coerce the file labelling to set <target> to
> some specified value for any symlink in a world-writable directory
That doesn't make sense. It isn't the world-writability that you care
about. It's preventing the program from following a potentially
untrusted symlink.
Simply denying all programs the ability to follow symlinks they don't
own is far too blunt of a hammer. For example, if we wanted to move the
Postgresql socket from /tmp, but still allow old applications to work,
we might create a symlink from /tmp/.postgres to /var/run/postgres. In
this case it's quite easy with SELinux to allow programs to read
the .postgres symlink by ensuring it's labeled correctly.
The point here is that SELinux does allow you to express your end
security goal. Most domains don't have the privileges to read lnk_file
except for symlinks created by their own domain.
> > By the way, I'm pretty sure your LSM is insufficient in the presence of
> > ACLs.
>
> OK.. So the directory *could* be non-world-writable but with an ACL that lets
> the victim in. If you get into this state with /tmp or /var/tmp or similar,
> then you've got bigger problems anyhow.. ;)
It's still discretionary, and thus subject to all of the problems of
discretionary access control. You have no way of knowing whether the
security goal is being enforced without verifying every directory on the
system, ensuring it doesn't have ACLs, etc. Also any uid 0 process can
quite easily subvert the controls.
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 11:34:54 PDT