Minor Bugfix v1.2.3-13

13. RES: Cannot reset FD resource settings

    * Urgency: Low.
    * What you see: After setting a res_min or res_max value for a 
filesystem object, setting it back to default value does not work, 
unless another value is also non-default.
    * What is wrong: The attribute struct is only updated, if some 
value is non-default. Otherwise it should be removed, but is not.
    * Implications: Inconvenience in administration.
    * Credits: Thanks to Murf for reporting this bug.
    * RSBAC versions affected: 1.2.2-1.2.3.
    * What you should do: Apply this patch (MD5 / GnuPG Cert) to get 
the bug corrected, recompile the kernel, reinstall and reboot.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBB/0Yzq9yn6h5RTo8RAs+CAJ0Vn5F9sxFacweysZ1XL5ptVuozqgCeMdF4
ZAf6a2nFESNcNlGR41cPrBo=
=XEA0
-----END PGP SIGNATURE-----

8eac4216d4581440c94cd24a504a2b97  rsbac-bugfix-v1.2.3-13.diff

kernel user management questions

Hello !
  Will you be so kind as to answer on couple questions?
   1. What benefits of "in-kernel user management" against
     traditional Linux user management subsystem?
   2. What parts of traditional Linux user management subsystem
     with "in-kernel user management" is no longer necessary
     (/etc/passwd, /etc/group, shadow suit and so on...)?
   3. How about programs and scripts wich relies on/work with
      /etc/passwd, /etc/group directly ?
Thanks a lot!
mailto:sftf <at> yandex.ru

Re: kernel user management questions

Hello everybody,

this is starting to become a FAQ. I am pretty glad about all the 
upcoming questions about the new User Management, because they show 
a lot of interest.

Official documentation has not yet been written, but will be as soon 
as I find the time. Volunteers are very welcome. I guess I will put 
this mail online soon.

On Donnerstag 03 Februar 2005 06:03, sftf <at> yandex.ru wrote:
> Hello !
>   Will you be so kind as to answer on couple questions?
>    1. What benefits of "in-kernel user management" against
>      traditional Linux user management subsystem?

The traditional Linux user management, specially the common 
passwd/shadow scheme with PAM, has several security problems:

1. PAM libraries running in process context:
The PAM libraries are mapped into every process, which has to 
authenticate users or change user accounts. This means that every 
single such process must have read or even write access to sensitive 
authentication data, and an exploit in only one of them reveals all 
this sensitive information to an attacker.  Not using PAM does not 
help here, because the process still needs the same access.

2. No granularity:
If a process has access to sensitive account or even authentication 
data of one user, it has access to the same for _all_ users in the 

Re: kernel user management questions

Hi,

On Thu, Feb 03, 2005 at 09:58:54AM +0100, Amon Ott wrote:
[...]
> On Donnerstag 03 Februar 2005 06:03, sftf <at> yandex.ru wrote:
> >   Will you be so kind as to answer on couple questions?
> >    1. What benefits of "in-kernel user management" against
> >      traditional Linux user management subsystem?
> 
> The traditional Linux user management, specially the common 
> passwd/shadow scheme with PAM, has several security problems:
> 
[...]
> 2. No granularity:
> If a process has access to sensitive account or even authentication 
> data of one user, it has access to the same for _all_ users in the 
> system, even the administration accounts.
> 
> 3. Changing passwords:
> Because of 2., a program which allows password changes by the user 
> (usually passwd), also has access to all passwords. An admin account 
> which is allowed to set new passwords for normal users, who tend to 
> forget their passwords, can do the same for any user - including 
> other admins. This means this admin can get access to all other admin 
> accounts, even if direct access is not allowed through RSBAC access 
> control.
> 
> 4. Password attacks:
> As encrypted passwords are readable for too many processes, they can 
> be guessed via dictionary attacks. Worse, the old crypt is easy to 

Re: kernel user management questions

On Donnerstag 03 Februar 2005 16:44, Dmitry V. Levin wrote:
> On Thu, Feb 03, 2005 at 09:58:54AM +0100, Amon Ott wrote:
> [...]
> > On Donnerstag 03 Februar 2005 06:03, sftf <at> yandex.ru wrote:
> > >   Will you be so kind as to answer on couple questions?
> > >    1. What benefits of "in-kernel user management" against
> > >      traditional Linux user management subsystem?
> > 
> > The traditional Linux user management, specially the common 
> > passwd/shadow scheme with PAM, has several security problems:
> > 
> [...]
> > 2. No granularity:
> > If a process has access to sensitive account or even 
authentication 
> > data of one user, it has access to the same for _all_ users in the 
> > system, even the administration accounts.
> > 
> > 3. Changing passwords:
> > Because of 2., a program which allows password changes by the user 
> > (usually passwd), also has access to all passwords. An admin 
account 
> > which is allowed to set new passwords for normal users, who tend 
to 
> > forget their passwords, can do the same for any user - including 
> > other admins. This means this admin can get access to all other 
admin 
> > accounts, even if direct access is not allowed through RSBAC 
access 
> > control.

kernel error by compiling

hi
id do the kernelsetup from 
http://www.gentoo.org/proj/en/hardened/rsbac/quickstart.xml.
and i get this error .

CC      rsbac/adf/pax/pax_main.o
rsbac/adf/pax/pax_main.c: In function `rsbac_pax_set_initial_flags_func':
rsbac/adf/pax/pax_main.c:66: warning: implicit declaration of function 
`pax_check_flags'
   LD      rsbac/adf/pax/built-in.o
   CC      rsbac/adf/pm/pm_syscalls.o
   CC      rsbac/adf/pm/pm_main.o
   LD      rsbac/adf/pm/built-in.o
   CC      rsbac/adf/rc/rc_syscalls.o
   CC      rsbac/adf/rc/rc_main.o
   LD      rsbac/adf/rc/built-in.o
   CC      rsbac/adf/reg/reg_main.o
   LD      rsbac/adf/reg/built-in.o
   CC [M]  rsbac/adf/reg/reg_sample1.o
   CC [M]  rsbac/adf/reg/reg_sample3.o
   CC [M]  rsbac/adf/reg/kproc_hide.o
   CC [M]  rsbac/adf/reg/modules_off.o
   CC [M]  rsbac/adf/reg/root_plug.o
   CC      rsbac/adf/res/res_main.o
   LD      rsbac/adf/res/built-in.o
   CC      rsbac/adf/sim/sim_main.o
   LD      rsbac/adf/sim/built-in.o
   LD      rsbac/adf/built-in.o
   CC      rsbac/data_structures/aci_data_structures.o
rsbac/data_structures/aci_data_structures.c: In function `rsbac_do_init':

Re: kernel error by compiling

On Sonntag 06 Februar 2005 09:08, jens kasten wrote:
> id do the kernelsetup from 
> http://www.gentoo.org/proj/en/hardened/rsbac/quickstart.xml.
> and i get this error .
> 
> CC      rsbac/adf/pax/pax_main.o
> rsbac/adf/pax/pax_main.c: In function 
`rsbac_pax_set_initial_flags_func':
> rsbac/adf/pax/pax_main.c:66: warning: implicit declaration of 
function 
> `pax_check_flags'

Please retry with "direct" MAC system integration in PaX kernel 
config.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

Transfer of RSBAC-settings from one machine to another

Hello,

I am trying to set up a backup-server (for redundancy) for our 
(RSBAC-protected) main-server. The backup-server has the same 
HDD-partitioning than his big brother, but the HDD is smaller (the 
backup-server is a rather normal PC (unlike the main-server which is a 
IBM xSeries server)). I want now to transfer the RSBAC-settings from the 
main-system to the backup-system, and would try to do this via the 
backup-script of RSBAC. Would this be the correct way to do this, or is 
there a better (perhaps safer) way to accomplish this ?

Thank you very much in advance.

Kind regards.
    Patrique Wolfrum

--

-- 
Patrique Wolfrum
Administrator - Fakultätsserver

Albert-Ludwigs-Universität Freiburg im Breisgau
Institut für allgemeine Wirtschaftsforschung
Abteilung für Wirtschaftsinformatik
Kollegiengebäude II
Platz der Alten Synagoge
79085 Freiburg

Tel.: 0761 - 203-2397 

xserver

hi
after many trys, iam not able to start the x-server.
the follow i do.
i go to the rsbac_menu -> rc_role  and make a new role X-server.
than i copy the rigth from system to this new role.
than i go to the fd_menu and choose /usr/X11R6/bin/X and 
/usr/X11R6/bin/XFree86 and set the RC_Force_Role to the X-server.
i enable als the auth to On. than i go to the Acl _menu and choose user 
root for this two binarys.
i also try acl_grant USER root GET_STATUS_DATA SCD kmem.
but when i do startx i get always
rsbac_adf_request(): request GET_STATUS_DATA, pid xx, ppid xx prog_name 
xfree86 uid0, target_type  SC, tid kmem, attr none, value 0, result 
NOT_GRANTET by RC.
now i do not know more, what i can do to start the server.
mfg
igraltist

Re: xserver

On Dienstag 08 Februar 2005 16:23, jens kasten wrote:
> after many trys, iam not able to start the x-server.
> the follow i do.
> i go to the rsbac_menu -> rc_role  and make a new role X-server.
> than i copy the rigth from system to this new role.
> than i go to the fd_menu and choose /usr/X11R6/bin/X and 
> /usr/X11R6/bin/XFree86 and set the RC_Force_Role to the X-server.
> i enable als the auth to On. than i go to the Acl _menu and choose 
user 
> root for this two binarys.
> i also try acl_grant USER root GET_STATUS_DATA SCD kmem.
> but when i do startx i get always
> rsbac_adf_request(): request GET_STATUS_DATA, pid xx, ppid xx 
prog_name 
> xfree86 uid0, target_type  SC, tid kmem, attr none, value 0, result 
> NOT_GRANTET by RC.
> now i do not know more, what i can do to start the server.

It is the RC role, which still denies access. Call rsbac_rc_role_menu, 
choose your X-server role, select Type Comp SCD, choose kmem and add 
GET_STATUS_DATA right.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22