File resource type: critical chmod security issue
Judd Maltin
file { '/tmp/default':
ensure => directory,
mode => '666'
}
produces:
root@blah# ls -la /tmp/default/
total 16
drwxrwxrwx 2 root root 4096 2009-07-27 16:21 .
That is a major security issue. I cannot recommend Puppet to my
clients if I get different results on my filesystem than from my
manifest.
Is there a consistent culture or policy in the Puppet community to
override explicit security configurations? It must be explicitly
avoided in an audit, if that's the case. If there is no policy,
perhaps we should define one?
Thanks a lot!
-judd
Joe McDonagh
--
Joe McDonagh
Operations Engineer
www.colonfail.com
Joe McDonagh
directories than files.
[~/Desktop] > umask
0077
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > mkdir test
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > ls -ld test
drwx------ 2 jmcdonagh jmcdonagh 4096 2009-07-27 16:48 test
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > touch testfile
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] > ls -l testfile
-rw------- 1 jmcdonagh jmcdonagh 0 2009-07-27 16:48 testfile
(jmcdonagh@jmcdonag) Mon Jul 27 04:48 PM /dev/pts/3
[~/Desktop] >
Peter Meier
> That is a major security issue. I cannot recommend Puppet to my
> clients if I get different results on my filesystem than from my
> manifest.
>
> Is there a consistent culture or policy in the Puppet community to
> override explicit security configurations? It must be explicitly
> avoided in an audit, if that's the case. If there is no policy,
> perhaps we should define one?
the only existing culture is that for file resources directories
automatically get the execute bit. I don't yet see why you'd like to
have a directory without the execute flag set, maybe you can explain?
This "feature" is one side very helpfull if you have recursive
directories to manage, maybe you know the other side where it isn't that
helpfull.
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.
cheers pete
James Turnbull
Hash: SHA1
Peter Meier wrote:
> 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
Regards
James Turnbull
- --
Author of:
* Pro Linux Systems Administration
(http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet
(http://tinyurl.com/pupbook)
* Pro Nagios 2.0
(http://tinyurl.com/pronagios)
* Hardening Linux
(http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKbhjH9hTGvAxC30ARAjGMAJwKwXqm6RdMsaz9MG2vwMxL4eqBCQCgkra9
LnbnMMfBjRQeS0fE386tiko=
=fuo7
-----END PGP SIGNATURE-----
Peter Meier
> the only existing culture is that for file resources directories
> automatically get the execute bit. I don't yet see why you'd like to
> have a directory without the execute flag set, maybe you can explain?
>
> This "feature" is one side very helpfull if you have recursive
> directories to manage, maybe you know the other side where it isn't that
> helpfull.
ok
http://www.wellho.net/mouth/2300_What-does-x-on-a-linux-directory-mean-.html
gave me some reasons, why you'd like to have the more strict way. I
outlined further things in the bug report:
http://projects.reductivelabs.com/issues/2451
> 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.
still interested.
cheers pete
Peter Meier
>> 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
Bruce Richardson
> > Is there a consistent culture or policy in the Puppet community to
> > override explicit security configurations? It must be explicitly
> > avoided in an audit, if that's the case. If there is no policy,
> > perhaps we should define one?
>
> the only existing culture is that for file resources directories
> automatically get the execute bit. I don't yet see why you'd like to
> have a directory without the execute flag set, maybe you can explain?
On a slight tangent, how about having 755 on a directory but (for
example) having 700 or 600 recursively on all the managed directories
and files underneath it (and maybe different ownership as well). There
are valid reasons for wanting to do this but the last time I tried it, I
found it impossible with puppet. Maybe I should look again to see what
I missed.
--
Bruce
I object to intellect without discipline. I object to power without
constructive purpose. -- Spock
Larry Ludwig
Larry Ludwig
> 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
>
> Regards
>
> James Turnbull
This sounds like a page for the wiki no? Any security issues ideally
should be reported privately first (at least with white hats).
-L
--
Larry Ludwig
Reductive Labs
Judd
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.
Trevor Vaughan
Hash: SHA1
- 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
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpuarMACgkQyjMdFR1108CYdACfaRuY5r37165GXT7A51FrDY4h
/hsAn0JZzPjG3WwPAJejtrKV37C3YCLz
=0/UX
-----END PGP SIGNATURE-----
Bryan Ross
>
> In any case it's VERY misleading to have an explicit command
> completely ignored by an unstated policy.
>
Personally, I'm not too worried about the security aspects of this,
but I would certainly expect Puppet to do what its told. If I fluff
my permissions, more fool me. However if I do, for whatever reason,
want a particular mode then Puppet should respect that.
With the current operation, there's very little flexibility. If we
add a 'dirmode' or something similar, as suggested by Luke in Bug
#2451, then Puppet can handle both cases. This seems like a no
brainer to me?
Cheers,
Bryan
Peter Meier
> On a slight tangent, how about having 755 on a directory but (for
> example) having 700 or 600 recursively on all the managed directories
> and files underneath it (and maybe different ownership as well). There
> are valid reasons for wanting to do this but the last time I tried it, I
> found it impossible with puppet. Maybe I should look again to see what
> I missed.
it is possible, but not that directly in one statement:
file{
'/a':
ensure => directory,
mode => 0755;
[ '/a/b', '/a/c' ]:
ensure => directory,
recurse => true
owner => user1, mode => 0600;
[ '/a/d', '/a/e' ]:
ensure => directory,
recurse => true,
owner => user2, mode => 0600;
}
and this is exactly the case where this automatic x-bit is really
nice. Do you envision any easier/more direct way to do it?
For sure you have to manage the content of each subdirectory
separately as they're managed on their own. But every other behavior
would simply lead to a too big headache.
cheers pete
Bruce Richardson
> For sure you have to manage the content of each subdirectory separately
> as they're managed on their own.
I'm sorry, but that fails as far as I'm concerned. I shouldn't be
having to specify common behaviour multiple times.
--
Bruce
Those who cast the votes decide nothing. Those who count the
votes decide everything. -- Joseph Stalin
James Turnbull
> Personally, I don't see the default behavior as a security flaw.
>
I tend to agree that the current behaviour meets 99% of the functional
requirements but I do understand where the original poster is coming from.
Like Luke, I don't see why an additional attribute can't be added but I
don't see it as a critical security issue. Not to say it should not be
developed but IMHO I see the risk of a compromise through this as low
and hence feel there is a low ROI in fixing it. If someone wants to
pony up some code and tests...
Regards
James Turnbull
Peter Meier
>> For sure you have to manage the content of each subdirectory separately
>> as they're managed on their own.
>
> I'm sorry, but that fails as far as I'm concerned. I shouldn't be
> having to specify common behaviour multiple times.
well either your managing a resource or you're not. Something between
will just lead to too many problems and conflicts. or which easier way
do you envision without having these problems?
cheers pete
Bruce Richardson
specify one behaviour for /a and another for /a/**. As I said, there
are valid reasons for wanting that.
--
Bruce
A problem shared brings the consolation that someone else is now
feeling as miserable as you.
Peter Meier
> OK, maybe I didn't express it clearly enough. Puppet won't let me
> specify one behaviour for /a and another for /a/**. As I said, there
> are valid reasons for wanting that.
I understood it that way and I also understand the reasons. My problem
is to see a valid way to describe that within the (existing or future)
puppet language, as well to fit it into the resource model, which
puppet is committed to.
so something like?
file{
'/a:
mode => 0755;
"/a/**":
mode => 0600;
}
but I'm not sure whether this wildcard resource is a good idea.
cheers pete
Trevor Vaughan
should be pretty easy :-) (magic, I say!).
Having a regex match on the File type would actually be useful in a
lot of cases. *But* it needs to be able to be sped up.
Something like forking to the native tools to do the match and perms
might work, but at least something that gets rid of the 'recursive
directory management nightmare' where you checksum and/or record
millions of files just because you wanted to only change the
permissions.
In any case, you could then do thing like:
foo/ -> 755
foo/*.conf -> 640
foo/*.user -> 644
But, I could see ordering becoming quite important in this case.
Extremely low priority even if people do decide that it is a good idea.
Trevor