On Wed, 27 Oct 2004 16:39:48 EDT, Stephen Smalley said: > So the obvious question is who can create tmp_t:lnk_file in the policy. > Answer: only privileged domains (and only indirectly via file > attributes that include that type, no direct rules). Daemon and user > domains all create their own $1_tmp_t types. This particular rule is > likely a legacy of post-install relabels where SELinux has no way of > knowing what to assign to existing /tmp files. But even that situation > no longer applies tmp_t to files under /tmp, per the current > file_contexts configuration. Foo.. the test I did: % cd /tmp % ln -s /etc/motd foo % chcon -h user_u:object_r:tmp_t foo % l -Z foo lrwxrwxrwx valdis valdis user_u:object_r:tmp_t foo -> /etc/motd Unfortunately, the box was in permissive mode at the time, rather than enforcing. I'm an idiot. :) > > 1) Don't follow a symlink out of a o+w directory (as pointed out, a special > > case of "don't follow an untrusted symlink". Here, the focus is in not > > tripping over a surprise left for you by others.. > > Seems like a straightforward tightening of the existing policy. > > > 2) Reject hard links to any non-regular file, any suid/sgid file, or > > any file you don't have write permission to yourself - here, we're trying > > to prevent the surprise from being set up. > > As we provide a per-file link permission, this is straightforward, > although it may require introducing additional types for suid/sgid > programs that don't already have a separate domain (not a bad thing > anyway). > > > 3) Reject writes to an "unsafe" FIFO (currently defined as "if it's in a > > world-writable dir, it has to be owned by you or the dir owner"). Again, > > the threat model is "you write to something other than you intended". > > Seems feasible to limit writes to fifos owned by your domain or a > trusted domain. Let me go ponder, I'll get back to this if/when I've cogitated more.. ;) What's the consensus - if these tightenings are done, should they just be done and see what breaks, or should they have an m4 ifdef around them and an entry in tunables/tunable.tun?
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 14:12:26 PDT