-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm slightly confused.
- From your original example, it looks like you're trying to create a
directory where everyone has read/write access, but nobody can traverse
the directory.
Perhaps this is the start of a symlink farm?
Most security guidance that I've read on the interwebs indicates that
world writable directories are fine so long as they are well documented
and they have the sticky bit set.
If I remember correctly, the reason that the 'file' type added the 'x'
to any directory is that the following applies to directories:
r -> I can read the file list
w -> I can write stuff to the directory
x -> I can traverse the directory
Testing a sample manifest as follows:
file { "/tmp/blah":
ensure => "directory",
mode => 540
}
You find:
dr-xr-x--- 2 4096 2009-07-27 22:54 /tmp/blah
So, what you're saying is that there may be a case where I want to be
able to list the contents of a directory but not traverse it? I've only
ever once used this construct and it wasn't very useful.
If you're trying to keep people from reading the contents, you want:
file { "/tmp/blah":
ensure => "directory",
mode => 551
}
Which works properly:
dr-xr-x--x 2 4096 2009-07-27 22:54 /tmp/blah
Now, you can traverse to anything under /tmp/blah, but you can't read
the contents of /tmp/blah, which is what you describe below.
Personally, I don't see the default behavior as a security flaw.
The scenario that you describe below in terms of user enumeration is
easier to affect using hooks into the standard PAM libraries, though
it's possible to protect against this as well. At a certain point
though, you're crippling your users' work space.
Finally, most mail systems that I've used chown the mail directories to
the target user. If this is not your experience, I would suggest taking
a look at the options behind Postfix and dovecot. If you have an actual
mail *server* you really shouldn't let your users onto it directly at all.
In essence, I think that the way Puppet currently handles directories
under the file type is both sane and correct, particularly in the
recursive case.
Perhaps, I'm missing something....James?
Thanks,
Trevor
On 07/27/2009 10:47 PM, Judd wrote:
> Thanks for following up on this..
>
> There are many instances when a user will be allowed access to a
> particular path, and not the containing directory's file list. Take a
> mail server or example, where a mail system user creates directories
> where users have access to their own files and folders, but not
> eachothers. It's also good for /home directory parents so people
> don't go perusing for other users.. but they certainly can rwx their
> own /home/user/*
>
> In any case it's VERY misleading to have an explicit command
> completely ignored by an unstated policy.
>
>
>
> On Jul 27, 5:18 pm, Peter Meier <peter.me...@immerda.ch> wrote:
>> Hi
>>
>>
>>
>>>> Could you outline what you'd like to have in this policy. Not explicitly
>>>> for this question you raised but more in general. Maybe it's indeed
>>>> interesting to have one.
>>> As someone who works as a security professional and has spent the
>>> last week interacting with a small army of auditors I vote that
>>> security policy is often a pain in the arse. :)
>>> There are some examples of FOSS security policies:
>>> http://www.debian.org/security/
>>> http://www.netbsd.org/support/security/
>>> And of course Google will show a few more up - I believe Mozilla has
>>> one.
>>> Generally speaking they define a few basics:
>>> 1. Who is accountable for security
>>> 2. What to do if you find a security issue and where to report
>>> security issues
>>> 3. How security patches are handled
>>> 4. The project's disclosure policy
>> ic, thought it's going into this direction, but wasn't sure. thanks!
>>
>> cheers pete
> >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpuarMACgkQyjMdFR1108CYdACfaRuY5r37165GXT7A51FrDY4h
/hsAn0JZzPjG3WwPAJejtrKV37C3YCLz
=0/UX
-----END PGP SIGNATURE-----
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
