Wednesday Apr 18, 2007

Limiting users to one login session (no coding required)

I've often seen a request for restricting users to having a single login session to a given machine at a time.  I've also seen requests for having a single login session network wide.  

My response to the first of these is usually, write a PAM module to do it, probably using the data stored in utmpx/wtmpx or have the module keep its own state.

My response to the second is usually - this is a much harder problem to implement client side and it is probably better to solve this in a networked authentication service such as in the LDAP directory by having it deny the login. However that can cause other problems; particularly in large deployments where there are multiple directory servers and where users need to authenticate to the LDAP server not just for initial login but for viewing the address book or for IMAP or SMTP authentication.

The first of these came up again yesterday on the general OpenSolaris discussion alias.  Instead of my usual "write a PAM module" response I worked out how to do this using the OpenSolaris resource control framework and no coding. 

 Here's how to do it:

Put each user into their own resource control project, see project(4) and resource_control(5) man pages for more information.

For each of those user projects set the maximum number of tasks that can be created to be 1.

For my example user 'jru' add this to /etc/project (or the project(4) database in your nameservice) to limit them to one login session.

Either edit /etc/project with an entry like this 

 user.jru:100::::project.max-tasks=(privileged,1,deny)

or use the projadd(1M) command like this:

 # projadd -K 'project.max-tasks=(privileged,1,deny)' user.jru

 

This uses the special 'user.' syntax which also makes this the initial project for the user jru. For this to work you also need to make sure that the user is NOT part of the special 'default' project, otherwise they would be able to use newtask(1) to create more tasks. To do that make the 'default' project not contain any users at all by setting the list of users in the project to '!\*' eg:

default:3::!\*::

This requires that all users on the system explicitly be a member of some project, either one for their user or assigned one they share with other users using the project keyword in user_attr(4) or a 'group.' project that is implicit based on their unix group membership. This is required since users are normally always in the 'default' project that we have just excluded all of them from.  If you don't do this they won't be able to login at all.  

Note that the root user already has a special 'user.root' project defined for them in the standard /etc/project file.

This is how it will look to users:

An attempt to login a second time (ie create a new task in the project) will fail, eg:

$ ssh jru@localhost
Resource control limit has been reached
$

An attempt to create more processes than is allowed will fail  something like this: 

$ sleep 500 &
zsh: fork failed: resource temporarily unavailable

 

All pretty easy and remember that you can do this network wide by putting the project(4) database in your nameservice of choice (NIS, NIS+, LDAP).

 

Update With respect to the comment from James: tasks are NOT UNIX processes.

Limiting the number of tasks a user can create does NOT limit the number of processes, so it doesn't
impact using pipes. In normal operation the only time a new task is created is at login time or by
explicitly running newtask(1) to create one or change the task a give process is in. tasks aren't a UNIX thing
but are part of the Solaris extended accounting system. Maybe I confused the issue by mentioning that
for a given project you can also limit the number of processes a user can have. To avoid that confusion
in the future I've removed that part so we only talk about tasks now.

 

Thursday Apr 05, 2007

ftp with GSS-API (Kerberos) authentication only

To change the configuration of the ftp daemon on Solaris so that it will only accept authentications from clients with GSS-API (probably Kerberos)

$ svccfg -s ftp setprop inetd_exec = "/usr/sbin/in.ftpd -a -K"
$ svcadm refresh ftp



Wednesday Mar 28, 2007

GUI Performance tools for OpenSolaris

For years I've wanted some eye candy way to show of the cryptographic framework, but when it comes down to it crypto just isn't that sexy when it comes to demos.

Well now at least there is a GUI that we can use to show what the framework is doing.  The jkstat project just started up on OpenSolaris, some of the screenshots of this look great.

We will be able to use this to display the kstats that the kernel crypto framework and its providers export to show visually what is going on. 

Even better I get to talk to the main author about this in person since he is one of the members of the London OpenSolaris User Group.   Hopefully I can sign him up to give a talk on this at one of our up and coming meetings.

 


 

Wednesday Mar 21, 2007

Notes on porting Racoon to OpenSolaris

Just some notes on porting Racoon to OpenSolaris that might be useful for any Google Summer of Code student who gets assigned to that project.

The first hurdle is the simple naming of some types, the Racoon code for some reason uses u_int32_t instead of uint32_t after running configure add the following to config.h:

 

#ifndef __P
#ifdef __STDC__
#define __P(p)  p
#else
#define __P(p)  ()
#endif
#endif  /\* !defined(__P) \*/

#define u_int8_t        uint8_t
#define u_int16_t       uint16_t
#define u_int32_t       uint32_t
#define u_int64_t       uint64_t

Raccoon seems to assume that the host has the KAME policy extensions available, OpenSolaris doesn't have this. Instead we have <sys/pfpolicy.h> so Racoon needs to be ported to the OpenSolaris PF_POLICY system.

Getting GSSAPI support working would also be very good.  The configure script trips on because the OpenSolaris /usr/bin/krb5-config script doesn't have an option for GSSAPI.

The rest is well thats up to whom ever picks up this project :-)
 


Monday Feb 05, 2007

VIA Padlock & OpenSolaris Crypto Framework

An inital prototype of a driver for the VIA Padlock has just been pushed into the OpenSolaris crypto framework.  At this time it only supports SHA-1 and SHA-256.  The plan is to get support for AES, RSA and random number.  Ultimately this driver should appear in the main ON consolidation of OpenSolaris and be available on all distributions including future Sun releases of Solaris.

Many thanks to Derek Morr for sharing his work on this via OpenSolaris.
 

Thursday Jan 18, 2007

Solaris & Sony PSP

I got a very interesting surprise when I plugged my Sony PSP into my laptop running Solaris Express build 54 (snv_54).  Not only did it mount the MemoryStick Duo card inside the PSP as a disk and have Nautilus great a new window for it (MacOS X managed that too), it got a music player icon on the desktop and Rhythmbox got started up.  I don't actually have any music on the memory stick in the PSP but Solaris now seems to understand that I might have.  Very cool indeed, I don't get iTunes popuping up on MacOS X when I plugin the PSP!

Monday Jan 08, 2007

OpenSolaris Zones: TX & BrandZ

Trusted Extensions (TX) integrated into OpenSolaris before BrandZ did so TX doesn't use the branded zone zones concept.  BrandZ wasn't just about providing the ability to run userland Linux code in a Zone it also provided an infrastructure to support different styles of zones, it doesn't even need to be some thing as complex as a Linux zone.  There are instructions on the brandz mail alias for creating a Belenix zone hosted on Solaris Express in this cases the branded zone doesn't require a different kernel module.

I think it should be possible to use the BrandZ hooks to avoid the need for doing some of the additional zone creation work that needs to be done manually for TX zones, or via tools like txzonemgr.

Currently lx branded zones (Linux ones) aren't allowed to exist if TX labeling is enabled but that is a different issue than using the BrandZ infrastructure to create TX zones.
 

Friday Jan 05, 2007

Updated webrev with Mercurial support

I've been updating my draft of the support for the Mercurial SCM system in the OpenSolaris webrev tool.  My latest version is available as webrev output generated by itself here.  This version is sync'ed up with Dan Price's recent changes.

Wednesday Dec 20, 2006

OpenSolaris Audit Project

A new OpenSolaris project on Auditing has just opened up today. This is to define and implement the future of the (BSM) Audit functionality.

If you are interested in Audit on OpenSolaris or it sister implementations on FreeBSD and MacOS X then please join us on in the audit-discuss mail alias on opensolaris.org.

Technorati Tags:

About

DarrenMoffat

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today