Tags:
create new tag
view all tags

Managing access.conf files

The pam_access module is a very useful and versatile way of doing authorization checks on users for various functionality which supports PAM. The obvious example is checking users at login time but it can also be used for such purposes as limiting access to privileged tasks (via consolehelper).

The LCFG auth component

Traditionally the only LCFG component to offer support for managing the contents of access.conf style files was the LCFG auth component via the auth.users resource. This takes a list of users, groups or netgroups and inserts them into a template to create a file (/etc/security/access.conf) like this:

#
# LCFG-generated file (auth component)
#
+:ALL:LOCAL
+:@foo:ALL
+:(bar):ALL
+:exampleuser:ALL
+:root:LOCAL
-:ALL:ALL

Where @foo is a netgroup and (bar) is a normal group. The problem here is that this template is rather inflexible, the origins field is hardwired to ALL for the entries which come from the auth.users resource. Also the first line and the root line are fixed. This is sufficient for a basic authorization check after the login stage but not much else. To address this issue we now have a new LCFG accessconf component.

The LCFG accessconf component

The accessconf component supports managing multiple different files, these are called "policies". Each policy has a set of rules which allow complete control of the fields but also have helpful defaults which avoid the need to specify more resources than strictly necessary.

Each rule has 3 resources which allow the setting of the action (allow or deny), the entity (user, group or netgroup) and the origin (ALL, LOCAL, IP address, domain name, etc).

The default action for a rule is to allow access. This makes sense when you consider that by default a policy is "default deny". It is possible to change a policy to "default allow", see the information on the "endrule".

To help simplify the specification a single rule can have multiple, whitespace-separated, entries in the entity list. This results in multiple lines being generated in the access.conf file, one for each entity, all with the same action and origin fields. If no entity is specified for a rule then then the name of the rule (which was added to the accessconf.policies taglist resource will be used.

The default value for the origin field is dependent on the type of the action for the rule. If the rule is to allow access then the default origin is LOCAL, if the rule is deny access then the default origin is ALL. This covers the most common situations and thus helps reduces the number of resources that must be set.

Examples

The most basic policy is to allow access to a single user:

#include <lcfg/options/accessconf.h>
!accessconf.policies         mADD(foo)
!accessconf.rules_foo      mADD(fred)

This will create a file (named /etc/security/foo.conf) which looks like this:

#
# LCFG-generated file (accessconf component)
#
+:fred:LOCAL
-:ALL:ALL

This authorizes the user fred on the local console and denies access to everyone else.

A more common situation is where you want to limit access to just the user to which the computer is allocated. The allocation is typically recorded through the sysinfo.allocated resource. Although it would be possible to insert that resource value into the rules taglist that would make it very difficult to set the associated origin resource. Much better is to do it like this:

#include <lcfg/options/accessconf.h>
!accessconf.policies                      mADD(foo)
!accessconf.rules_foo                   mADD(allocated)
!accessconf.entity_foo_allocated  mSET(<%sysinfo.allocated%>)
!accessconf.origin_foo_allocated  mSET(ALL)

This sets the origin field for the allocated user to ALL instead of the default LOCAL. That could be used, for instance, to allow the allocated user to SSH into the machine from anywhere but block all others.

When a netgroup is required (which has a @ prefix) or a group which is enclosed in () then the entities are specified separately like this:

!accessconf.policies                                   mADD(poweroff)
!accessconf.rules_poweroff                       mSET(allocated sysmans techs root)
!accessconf.entity_poweroff_allocated      mSET(<%sysinfo.allocated%>)
!accessconf.entity_poweroff_sysmans      mSETQ('@sysmans')
!accessconf.entity_poweroff_techs           mSETQ('(techs)')

If the permitted origins are the same for all users then it can be simpler to use a form like this:

!accessconf.policies                          mADD(access)
!accessconf.rules_access                 mSET(ALL users root)
!accessconf.entity_access_users     mSETQ('@foo (bar) exampleuser')
!accessconf.origin_access_users     mSET(ALL)

This produces an access.conf like:

#
# LCFG-generated file (accessconf component)
#
+:ALL:LOCAL
+:@foo:ALL
+:(bar):ALL
+:exampleuser:ALL
+:root:LOCAL
-:ALL:ALL

which is identical to the output from the LCFG auth component when the value of the auth.users resource is set to @foo (bar) exampleuser

Default Deny or Default Allow?

A policy can be either default deny or default allow. This behaviour is controlled using the endrule resources for a policy. By default a policy is default deny which means the final line looks like this:

-:ALL:ALL

You can change it to default allow by setting the relevant endrule_action resource (e.g. for a policy named foo the resource name is accessconf.endrule_action_foo) to allow.

There are similar endrule_entity and endrule_origin resources which control the other fields. Note that unlike the main rules list the entity field for the endrule is not expanded, it is expected to be a simple, single entity, normally it's going to be ALL.

If you do not want any rule added to the end of a policy file (possibly it's too complex and you want to do it using the main rules list) then you can set the value of the endrule_action resource to none.

Controlling the file name

The name of the generated access.conf for a policy comes from the name of the policy (e.g. foo) with a .conf suffix and it will be created in the directory specified in the accessconf.configdir resource (the default is /etc/security). So, for a policy named foobar you get a file path of /etc/security/foobar.conf.

If you wish to change the path for a policy to something else you can either specify a relative name which is then created within the accessconf.configdir directory or you can specify an absolute path. If the filename does not end in .conf then that suffix will be appended. This can be done using the file resource like this:

!accessconf.policies                   mADD(poweroff)
!accessconf.file_poweroff              mSET(access.halt-reboot.conf)

-- Main.squinney - 2013-02-14

Topic revision: r1 - 2013-02-14 - squinney
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback