From: "Justin P. Mattock" <justinmattock@gmail.com>
To: Amon Ott <ao@rsbac.org>
Cc: linux-kernel@vger.kernel.org, SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: Announce: RSBAC 1.4.0 released
Date: Fri, 16 Jan 2009 01:28:02 -0800 [thread overview]
Message-ID: <49705322.8010309@gmail.com> (raw)
In-Reply-To: <200901160948.32172.ao@rsbac.org>
Amon Ott wrote:
> Rule Set Based Access Control (RSBAC) 1.4.0 has been released for both
> Linux kernels 2.4.37 and 2.6.27.10
> You can download the new version from http://www.rsbac.org
>
> RSBAC is one of the leading access control systems for the Linux
> kernel with a good selection of access control models, see
> http://www.rsbac.org/why for more details.
>
> Important changes since 1.3 series:
>
> * VUM (Virtual User Management) support (http://rsbac.org/redir.php?t=vum)
> * One time password support for user management
> (http://rsbac.org/redir.php?t=otp)
> * Code for kernels 2.4 and 2.6 has been separated. 2.4 kernels might
> be phased out at a later date.
> * PAM module does not send a message "User not authenticated" anymore
> if authentication failed. (To match other PAM modules behavior)
> * Made PAM password prompt standard and definable to RSBAC's custom
> prompt if the user wants it only.
> * rsbac_useradd -K to copy a user with password.
> * rsbac_mount now uses kernel's vfs_mount
>
>
> About RSBAC 1.4:
> ---
>
> RSBAC 1.4 mainly introduces the new Virtual User Management feature (
> (http://rsbac.org/redir.php?t=vum),
> which allows to isolate complete sets of users in so-called "virtual sets".
> Every user in every set can have individual passwords and access rights.
>
> As an example, you can start your mail server in a different set, and
> the users getting the email will not be part of the system users.
>
> Likewise, your jails can be started in a different set, so that the
> users in that jail will never be the same ones as the real system users.
>
> You can specify the user set with the usual tools by specifying the
> full user path, e.g.:
>
> 0/0 defines user id 0 (root) in virtual set 0 (eg system user root)
> 0/1000 defines user id 1000 in virtual set 0 (eg a system user)
> 1/secoff defines user secoff in virtual set 1 (e.g. with uid 400)
> 2/1000 defines user id 1000 in virtual set 2 (for example, mail users
> could be in set 2)
>
> Amon.
>
alright a new security mechanism!!
(still need to learn UBAC though);
Anyways I'll have to give this a shot.
regards;
Justin P. Mattoxk
next prev parent reply other threads:[~2009-01-16 9:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 8:48 Amon Ott
2009-01-16 9:28 ` Justin P. Mattock [this message]
2009-01-16 10:15 ` Justin P. Mattock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49705322.8010309@gmail.com \
--to=justinmattock@gmail.com \
--cc=ao@rsbac.org \
--cc=linux-kernel@vger.kernel.org \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome