Puppet users - Nov 2010 - Prevent users from creating new accounts

Hi, all

I want to control the user accounts on our company servers with
puppet. The complete requirements are the following:

1. Assuming that one user run " useradd ...." on the server to create
a new account named "newuser".
2. Puppet will konw the new user created soon, and restore the server
status to the before. That is, puppet will delete the new user.


I am not sure if puppet could fullfill this requirement. Could anyone
give me some advices.

Thanks
hywl51

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday 04 Nov 2010 10:40:02 Martin Alfke wrote:
> On Nov 4, 2010, at 8:28 AM, hywl51 wrote:
> > Hi, all
> > 
> > I want to control the user accounts on our company servers with
> > puppet. The complete requirements are the following:
> > 
> > 1. Assuming that one user run " useradd ...." on the server
to create
> > a new account named "newuser".
> > 2. Puppet will konw the new user created soon, and restore the server
> > status to the before. That is, puppet will delete the new user.
> > 
> > 
> > I am not sure if puppet could fullfill this requirement. Could anyone
> > give me some advices.
> > 
> > Thanks
> > hywl51
> 
> Hi,
> 
> I would assume that you can define a resource default:
> 
> User { ensure => absent }
> 
> and afterwards define the users you would like to be present on your
> system.
Would this not mean the deletion and creation of all users on the system every 
30 minutes (or whatever your puppet run is set to?)

I would respectfully suggest that the best way to prevent users from adding 
new accounts on your systems (which is how I understand your question) is to 
restrict those individual''s rights on the systems, not to make sure
that you
undo any "damage" they may have done whilst logged in every time
puppet runs.

M.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Nov 4, 2010, at 12:28 AM, hywl51 wrote:
> Hi, all
> 
> I want to control the user accounts on our company servers with
> puppet. The complete requirements are the following:
> 
> 1. Assuming that one user run " useradd ...." on the server to
create
> a new account named "newuser".
> 2. Puppet will konw the new user created soon, and restore the server
> status to the before. That is, puppet will delete the new user.
> 
> 
> I am not sure if puppet could fullfill this requirement. Could anyone
> give me some advices.

Puppet isn''t good at requests phrased that way.  I don''t use
puppet to say, "make X stay how it currently is".  Instead you say,
"Make X be the state I declare."

You could push out /etc/passwd and /etc/group with Puppet, but you would need to
be careful.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Nov 4, 2010, at 8:28 AM, hywl51 wrote:
> Hi, all
> 
> I want to control the user accounts on our company servers with
> puppet. The complete requirements are the following:
> 
> 1. Assuming that one user run " useradd ...." on the server to
create
> a new account named "newuser".
> 2. Puppet will konw the new user created soon, and restore the server
> status to the before. That is, puppet will delete the new user.
> 
> 
> I am not sure if puppet could fullfill this requirement. Could anyone
> give me some advices.
> 
> Thanks
> hywl51

Hi,

I would assume that you can define a resource default:

User { ensure => absent }

and afterwards define the users you would like to be present on your system.

Martin

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

If puppet can not fullfill this requirement, is there any other tool
or solution to solve it?

On Nov 4, 5:34 pm, Patrick <kc7...@gmail.com>
wrote:
> On Nov 4, 2010, at 12:28 AM, hywl51 wrote:
>
> > Hi, all
>
> > I want to control the user accounts on our company servers with
> > puppet. The complete requirements are the following:
>
> > 1. Assuming that one user run " useradd ...." on the server
to create
> > a new account named "newuser".
> > 2. Puppet will konw the new user created soon, and restore the server
> > status to the before. That is, puppet will delete the new user.
>
> > I am not sure if puppet could fullfill this requirement. Could anyone
> > give me some advices.
>
> Puppet isn''t good at requests phrased that way.  I don''t
use puppet to say, "make X stay how it currently is".  Instead you
say, "Make X be the state I declare."
>
> You could push out /etc/passwd and /etc/group with Puppet, but you would
need to be careful.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Yes, you said it. Unfortunately, we have some users running as root
privilege on server,  because they cann''t work without it.

But we don''t want them to add new users on their own, so we hope find
a way that will delete all illegal users on the system every 30
minute.



On Nov 4, 5:02 pm, Matt Wallace <li...@truthisfreedom.org.uk>
wrote:
> On Thursday 04 Nov 2010 10:40:02 Martin Alfke wrote:
>
>
>
> > On Nov 4, 2010, at 8:28 AM, hywl51 wrote:
> > > Hi, all
>
> > > I want to control the user accounts on our company servers with
> > > puppet. The complete requirements are the following:
>
> > > 1. Assuming that one user run " useradd ...." on the
server to create
> > > a new account named "newuser".
> > > 2. Puppet will konw the new user created soon, and restore the
server
> > > status to the before. That is, puppet will delete the new user.
>
> > > I am not sure if puppet could fullfill this requirement. Could
anyone
> > > give me some advices.
>
> > > Thanks
> > > hywl51
>
> > Hi,
>
> > I would assume that you can define a resource default:
>
> > User { ensure => absent }
>
> > and afterwards define the users you would like to be present on your
> > system.
>
> Would this not mean the deletion and creation of all users on the system
every
> 30 minutes (or whatever your puppet run is set to?)
>
> I would respectfully suggest that the best way to prevent users from adding
> new accounts on your systems (which is how I understand your question) is
to
> restrict those individual''s rights on the systems, not to make
sure that you
> undo any "damage" they may have done whilst logged in every time
puppet runs.
>
> M.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Nov 4, 4:34 am, Patrick <kc7...@gmail.com>
wrote:
> On Nov 4, 2010, at 12:28 AM, hywl51 wrote:
>
> > Hi, all
>
> > I want to control the user accounts on our company servers with
> > puppet. The complete requirements are the following:
>
> > 1. Assuming that one user run " useradd ...." on the server
to create
> > a new account named "newuser".
> > 2. Puppet will konw the new user created soon, and restore the server
> > status to the before. That is, puppet will delete the new user.
>
> > I am not sure if puppet could fullfill this requirement. Could anyone
> > give me some advices.
>
> Puppet isn''t good at requests phrased that way.  I don''t
use puppet to say, "make X stay how it currently is".  Instead you
say, "Make X be the state I declare."
That''s quite right.  However, Puppet supports the state you declare
encompassing exactly a specific set of users, or even exactly a
specific set of users having UIDs greater than a minimum threshold.

PROVIDED THAT you use Puppet to manage all the ordinary user accounts
you _do_ want, you can instruct it that no other non-system accounts
should be present.  Do so by adding this metaresource to your
manifest:

resources { "user":
    purge => true,
    unless_system_user => 499
}

The value of the ''unless_system_user'' property is the
numerically
greatest UID that is considered a "system" user (administrative and
system services accounts), and thus not to be deleted.  499 is the
correct value for the standard setup of RedHat-family Linuxes; for
some other systems it would be 99, or perhaps some other number.  Read
the docs for (a bit) more detail.

I suspect that this will not remove user home directories, but that''s
not documented and I have not tested it.

You should be able to do the same for groups, if you wish, but I don''t
think there is a built-in concept of system groups parallel to that of
system users.
> You could push out /etc/passwd and /etc/group with Puppet, but you would
need to be careful.
Indeed so.

Alternatively, you could perhaps take an altogether different approach
by relying on LDAP or NIS for user authentication.  That would work
best if the same set of users should have access to all the systems
you''re managing, or if you can at least categorize the systems into a
small number of sets that each share a common pool of users (each set
would then need its own NIS or LDAP domain).  This assumes that your
local administrative accounts are not empowered to add new users in
LDAP/NIS.

As a third alternative, it ought to be possible to address the
underlying problem with judicious configuration of sudo, or, if that''s
not sufficient, with SELinux (if you''re using Linux).  With these
approaches the objective would be to grant users the ability to
perform the tasks they need to perform, without empowering them to
manage users.


John

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 11/04/2010 10:40 AM, Martin Alfke wrote:
> 
> On Nov 4, 2010, at 8:28 AM, hywl51 wrote:
> 
>> Hi, all
>>
>> I want to control the user accounts on our company servers with
>> puppet. The complete requirements are the following:
>>
>> 1. Assuming that one user run " useradd ...." on the server
to create
>> a new account named "newuser".
>> 2. Puppet will konw the new user created soon, and restore the server
>> status to the before. That is, puppet will delete the new user.
>>
>>
>> I am not sure if puppet could fullfill this requirement. Could anyone
>> give me some advices.
>>
>> Thanks
>> hywl51
> 
> 
> Hi,
> 
> I would assume that you can define a resource default:
> 
> User { ensure => absent }
> 
> and afterwards define the users you would like to be present on your
system.
Not at all. This default will apply to all users that you define in your
manifest. So this

user { [ "www-data","cron" ]: }

will indeed ensure those user''s absence, but puppet has no concept of
"remove resources I have not declared anywhere".

So unless you prune /etc/passwd, /home etc., this will do you not as
much good as you hope.

Someone brought up the issue that puppet would erase and recreate all
users during every run. That isn''t how puppet works either. This

User { ensure => absent }
user { "www-data": ensure => present }

will make puppet do nothing if the user exists already. Which is good,
but of no help to the OP''s problem.

Cheers,
Felix

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

It sure sounds like you need to be distributing a canonical
/etc/passwd, /etc/shadow, and /etc/groups on every puppet run.

* hywl51 <hywl51 at gmail.com> [2010/11/04 03:11]:
> Yes, you said it. Unfortunately, we have some users running as
> root privilege on server,  because they cann''t work without it.
> 
> But we don''t want them to add new users on their own, so we hope
> find a way that will delete all illegal users on the system every
> 30 minute.
-- 
To believe in something, and not to live it, is dishonest.
    -- Mohandas K Gandhi

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

Am Do den  4. Nov 2010 um 11:11 schrieb hywl51:
> Yes, you said it. Unfortunately, we have some users running as root
> privilege on server,  because they cann''t work without it.
For me that sounds that you should never give such users root rights.

If you give it to them they will have all rights.

Surely there are ways to prevent alternation of files (like /etc/passwd
or /etc/shadow) but if you or someone has root rights he or she can
easily change this back.
> But we don''t want them to add new users on their own, so we hope
find
> a way that will delete all illegal users on the system every 30
> minute.
And what if such a user disable puppet at all?

This sounds like a human problem. You can not solve them technical.

Regards
   Klaus
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBTNO5fZ+OKpjRpO3lAQo3LAf/WHFZ5Ka5VnF28BHssYcbhXCzDdQ17S3k
TI6N1aMrxsjlnv+QfZg9AKCvgFxOAYwMVJc/55fxbS77bbiRUcixpD98kolrV2nw
0c2f12qjmRoBkUNL2O5BziiTinR74QJSXarxfgthlArS9MbYCW7kJliB7wt/3PlY
LUgNldqsAMLqRwuyvkswEkglTRgDcPSoClC5Fs+QgfBYy2rRG5MHGFUtPFhNcgi2
okVM0sdsBv3fmX4FfIuL1GRqrifXqRx99cqjV6eZJTpfgj5GXLE5TvSku4LdseGI
SXpVc9KMhNXnjhiP/gZ+E/6rDh+Jg8X6/KN/CvxgtOxaoJF8GVVJJw==ik4m
-----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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Nov 04, 2010 at 10:40:02AM +0100, Martin Alfke
wrote:
> 
> Hi,
> 
> I would assume that you can define a resource default:
> 
> User { ensure => absent }
> 
> and afterwards define the users you would like to be present on your
system.
No, that would only establish the default for any user resources
declared within Puppet.  It would have no effect on users created
outside of puppet with names not used in Puppet.

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Nov 04, 2010 at 03:11:43AM -0700, hywl51 wrote:
> Yes, you said it. Unfortunately, we have some users running as root
> privilege on server,  because they cann''t work without it.
Are they admins or developers?  If developers, then there is always a
way round - sudo, fakeroot, giving them virtual hosts to play with.  If
they really need to be adminning the boxes then sudo will take you so
far, but past a certain point they have enough privileges to give
themselves more privileges.  SELinux might be the answer, although
you''d
have to use it carefully if you wanted to avoid it locking puppet down
as well.  And if puppet isn''t locked down, and they have root access...


-- 
Bruce

A problem shared brings the consolation that someone else is now
feeling as miserable as you.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Nov 4, 9:23 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 11/04/2010 10:40 AM, Martin Alfke wrote:
> > I would assume that you can define a resource default:
>
> > User { ensure => absent }
>
> > and afterwards define the users you would like to be present on your
system.
>
> Not at all. This default will apply to all users that you define in your
> manifest. So this
>
> user { [ "www-data","cron" ]: }
>
> will indeed ensure those user''s absence,
Correct.
> but puppet has no concept of
> "remove resources I have not declared anywhere".
Incorrect.  See the discussion above of the "resources" meta-type.  It
can be used to purge unmanaged resources of any type.  In fact, that
seems currently to be its *sole* use.

I agree with several others'' comments, however, that this is a problem
that should not arise.  It is rarely necessary to grant users
unfettered administrative rights to any system, and when such rights
are granted it is a bit silly to try to restrict them by the back
door.  A user with such access and an intent to do harm has so many
ways to go about it that you will never block them all.  Instead, give
users the means to perform only those administrative functions they
need to perform, taking care to protect against privilege escalation.

If a user really does need complete administrative access, then he is
a de facto sysadmin, and he should be saddled with all the
corresponding responsibilities.  If necessary, you can rope off his
computer in a DMZ, or otherwise protect the rest of your network from
it, but you cannot protect a computer from its own admin.


John

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

2010/11/4 hywl51 <hywl51@gmail.com>
> If puppet can not fullfill this requirement, is there any other tool
> or solution to solve it?
> [...]
>
There are several solutions you can use to audit your system. You can log
all events to a central server which might not be sufficent because root can
stop reporting or you can use things like PowerBroker to restrikt and audit
access to root or other accounts (
http://www.beyondtrust.com/PowerBroker-Servers-Unix.aspx?section=PowerBroker-Servers-Unix).
I''m still searching for something comparable based on an open source
solution but didn''t find something yet.

Kind regards, Thomas

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

* Bruce Richardson <itsbruce at workshy.org> [2010/11/05
09:01]:
> [...]  If developers, then there is always a way round - sudo,
> fakeroot, giving them virtual hosts to play with.
I''d like to second the virtual host suggestion -- throwaway VMs (or
zones, in solaris) work really well for this kind of situation.
Additionally, they reinforce repeatability, automation, and
encapsulation, qualities that sysadmins desire but developers tend
to be ignorant of.

-- 
If history teaches us anything, it''s that everyone will be part of
the problem, but not everyone will be part of the solution.
    -- Larry Wall

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.