Announce: RSBAC 1.4.0 released

Announce: RSBAC 1.4.0 released

[Amon Ott]

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.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

Re: Announce: RSBAC 1.4.0 released

[Justin P. Mattock]

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Announce: RSBAC 1.4.0 released

[Justin P. Mattock]

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

Re: Announce: RSBAC 1.4.0 released

[Joshua Brindle]

Justin P. Mattock wrote:
> 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 ( be.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!!

RSBAC has been around quite some time actually. It is not SELinux 
related and does not use LSM to place its security hooks and therefore 
is not viable for the upstream kernel. It is an addon kernel patch.

> (still need to learn UBAC though);

UBAC is an SELinux policy, in some ways it demonstrates the flexibility 
of the SELinux policy language. RSBAC is a framework for many security 
modules (sort of like a heavier-weight LSM). Currently it doesn't have a 
module with as expressive a policy language as SELinux. The only MAC 
module is a Bell and LaPadula implementation (though it does have role 
based access control, access control lists and others).

> Anyways I'll have to give this a shot.
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Announce: RSBAC 1.4.0 released

[Justin P. Mattock]

Joshua Brindle wrote:
> Justin P. Mattock wrote:
>> 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 ( be.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!!
>
> RSBAC has been around quite some time actually. It is not SELinux 
> related and does not use LSM to place its security hooks and therefore 
> is not viable for the upstream kernel. It is an addon kernel patch.
>
>> (still need to learn UBAC though);
>
> UBAC is an SELinux policy, in some ways it demonstrates the 
> flexibility of the SELinux policy language. RSBAC is a framework for 
> many security modules (sort of like a heavier-weight LSM). Currently 
> it doesn't have a module with as expressive a policy language as 
> SELinux. The only MAC module is a Bell and LaPadula implementation 
> (though it does have role based access control, access control lists 
> and others).
>
>> Anyways I'll have to give this a shot.
>>
>
>
I thought RSBAC was newly created.
didn't know it was as old as SELinux  :^)
(I wasn't trying to be rude by adding the CC's,
but now am glad); I'm going to read up
on RSBAC to get a better idea of how it
works.

regards;

Justin P. Mattock


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Announce: RSBAC 1.4.0 released

[Justin P. Mattock]

Joshua Brindle wrote:
> Justin P. Mattock wrote:
>> 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 ( be.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!!
>
> RSBAC has been around quite some time actually. It is not SELinux 
> related and does not use LSM to place its security hooks and therefore 
> is not viable for the upstream kernel. It is an addon kernel patch.
>
>> (still need to learn UBAC though);
>
> UBAC is an SELinux policy, in some ways it demonstrates the 
> flexibility of the SELinux policy language. RSBAC is a framework for 
> many security modules (sort of like a heavier-weight LSM). Currently 
> it doesn't have a module with as expressive a policy language as 
> SELinux. The only MAC module is a Bell and LaPadula implementation 
> (though it does have role based access control, access control lists 
> and others).
>
>> Anyways I'll have to give this a shot.
>>
>
>
So with a quick glance,
rsbac is kind of like /etc/groups
except rsbac has it's own entry?
(then for what app you want to run
you just rsbac_useradd  -d *)

regards;

Justin P. Mattock

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Announce: RSBAC 1.4.0 released

[Justin P. Mattock]

Ahh.. I couldn't help it
(really excited for a new feature
In security); jumped the gun with
Adding cc's(I'll try not to do that);

Regards;

justin P. Mattock



On Jan 16, 2009, at 12:48 AM, Amon Ott <ao@rsbac.org> 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.
> -- 
> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/