headers
Javier J. Martínez Cabezón | 1 Jan 2009 03:54
Picon

Re: About the maintenment finishes in hardened gentoo

Don't be worried, I didn't use gentoo rsbac ebuilds :-D. But thanks
and... happy new year

2008/12/30 Daniel Cegielka <daniel.cegielka <at> gmail.com>:
> Javier J. Martínez Cabezón pisze:
>> Hi, I want to ask you about one question, it appears that rsbac is not
>> maintained in gentoo hardened furthermore, I thought that the main
>> maintainer was kang, what happened? Did kang decide to change to
>> grsecurity or has changed to windows vista? o:-).
>>
>> With all thanks for your work maintaining it all this time.
>>
>> PD: please get realized, I have in good consideration grsecurity...
>> _______________________________________________
>> rsbac mailing list
>> rsbac <at> rsbac.org
>> http://www.rsbac.org/mailman/listinfo/rsbac
>
> I forgot about this! I have ebuild for rsbac-sources with genpatches v5
> and PaX (with some fix-patch). But I have some problem with rsbac-admin
> tools. So I wait for stable version (its good idea), but if you really
> need this I can send you.
>
> daniel
> _______________________________________________
> rsbac mailing list
> rsbac <at> rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Cegielka | 1 Jan 2009 12:58
Picon

Re: rsbac menu problems

THX for help Javier ;)

There is small problem with gpm.
rsbac_menu works fine on hardened gentoo if you start gpm
(/etc/init.d/gpm start) or you can recompile ncurses with USE="-gpm"

Javier J. Martínez Cabezón pisze:
> /tmp is not full, I have not configured gpm (I don't use the mouse, so
> had the default values) so it could be perfectly the second scenario
> you gave mention.
> 
> 2008/12/21 Amon Ott <ao <at> rsbac.org>:
>> Am Sonntag 21 Dezember 2008 schrieb Javier J. Martínez Cabezón:
>>> Hi folks, when using the dialog rsbac_menu interface (or another one)
>>> program if you switch any item it appears the following message error:
>>>       Main Menu: Selection Error!.
>>>
>>> I'm running one gentoo hardened linux under a VirtualBox environment,
>>> installed and updated from 2008 version (with not extra USE flags and
>>> only with a -D_FORTIFY_SOURCE=2 flag used to compile by default). It
>>> seems to be related with gpm (this gentoo version comes with
>>> 1.20.1-r6). I resolved it simply removing the gpm package. Have anyone
>>> in the mailing list had the same problem?
>>>
>>> I don't know yet what made it fail, but I send this feedback because
>>> is an silly and stupid problem enough to make you lose your time.
>> So far, I have only seen that error when the partition with /tmp was read-only
>> or full.
>>
>> Can it be that dialog spits out gpm errors on stderr, too, so that the real
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amon Ott | 7 Jan 2009 12:48

Re: 1.4.0-rc3 check_comp_rc: rc_role wrong?

Am Dingsdag 25 November 2008 schrieb Amon Ott:
> On Monday 24 November 2008 22:44, Bernhard Seibold wrote:
> > On Di, 2008-11-18 at 16:52 +0100, Amon Ott wrote:
> > > On Monday 17 November 2008 19:32, Bernhard Seibold wrote:
> > > > User 1000 is rc_role 4. No errors with 2.6.26.7 with 1.4.0-rc2
> > > > (and your one-line ipv6 patch).
> > > >
> > > > 0000009047|check_comp_rc(): pid 2299432064 (gweather-applet),
> > > > owner 1000, rc_role 0, NETOBJ rc_type 0, request CREATE ->
> > > > NOT_GRANTED!
> > >
> > > The pid is complete rubbish here. Just corrected output at
> > > several places. I have attached a patch, can you please retry
> > > with it?
> >
> > The PIDs are now ok, but of course the problem persists. This was
> > logged while starting Apache (in Softmode, by user 1000 from a
> > "sudo -s" shell), with debug_adf_auth and debug_adf_rc turned on:
> >
> > 0000002834|rsbac_set_attr(): Trying to set attribute for process 0!
> > 0000002835|rsbac_adf_set_attr_rc: rsbac_set_attr() for rc_role
> > returned error!
>
> Right. The problem is that the pid struct pointer is null here, this
> is what triggers these error messages. Now I have to find out why.
>
> All other errors you have listed are consequences of this.

Can you please retest with latest svn code? Another user reported that these 
problems are now finally gone for him.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernhard Seibold | 8 Jan 2009 02:37
Picon
Favicon

Re: 1.4.0-rc3 check_comp_rc: rc_role wrong?

On Mi, 2009-01-07 at 12:48 +0100, Amon Ott wrote:
> Am Dingsdag 25 November 2008 schrieb Amon Ott:
> > On Monday 24 November 2008 22:44, Bernhard Seibold wrote:
> > > On Di, 2008-11-18 at 16:52 +0100, Amon Ott wrote:
> > > > On Monday 17 November 2008 19:32, Bernhard Seibold wrote:
> > > > > User 1000 is rc_role 4. No errors with 2.6.26.7 with 1.4.0-rc2
> > > > > (and your one-line ipv6 patch).
> > > > >
> > > > > 0000009047|check_comp_rc(): pid 2299432064 (gweather-applet),
> > > > > owner 1000, rc_role 0, NETOBJ rc_type 0, request CREATE ->
> > > > > NOT_GRANTED!
> > > >
> > > > The pid is complete rubbish here. Just corrected output at
> > > > several places. I have attached a patch, can you please retry
> > > > with it?
> > >
> > > The PIDs are now ok, but of course the problem persists. This was
> > > logged while starting Apache (in Softmode, by user 1000 from a
> > > "sudo -s" shell), with debug_adf_auth and debug_adf_rc turned on:
> > >
> > > 0000002834|rsbac_set_attr(): Trying to set attribute for process 0!
> > > 0000002835|rsbac_adf_set_attr_rc: rsbac_set_attr() for rc_role
> > > returned error!
> >
> > Right. The problem is that the pid struct pointer is null here, this
> > is what triggers these error messages. Now I have to find out why.
> >
> > All other errors you have listed are consequences of this.
> 
> Can you please retest with latest svn code? Another user reported that these
(Continue reading)

Permalink | Reply | 0 comments |
headers
Javier J. Martínez Cabezón | 10 Jan 2009 18:54
Picon

About ACCESS_CONTROL and SUPERVISOR rights

Hi I only need confirmation about one concept. If I didn't
missunderstand the concept:

If I have one rol named gerency_r that admin the roles Technician_r,
nurses_r and Doctor_r, Technician_r has write_only rights to
patient_data_t type, Doctor_r has read-write access granted to it and
nurses_r only read-only.
 If secoff grants ACCESS_CONTROL right to patient_data to rol
gerency_r then gerency_r could add or remove standard DAC rights
access to all data from this type involving this three roles isn't it?
 If secoff grants SUPERVISOR right to patient_data type to rol
gerency_r then gerency_r could add or remove any RSBAC rights access
to this type involving this three roles. Is this correct?
Permalink | Reply | 4 comments |
headers
Javier J. Martínez Cabezón | 11 Jan 2009 00:48
Picon

About SCD T_swap.

Hi all, while looking some code of 1.3.7 rsbac version (swapfile.c)
when you add one partition/file with swapon and swapoff it only checks
that you own the capability CAP_SYS_ADMIN and if you have
MODIFY_SYSTEM_DATA in SCD_swap and ADD_TO_KERNEL rights in the
file/device to add. ADD_TO_KERNEL (and REMOVE_TO_KERNEL) to SCD_swap
is ignored isn't it?. I'm wrong thinking that the only right useful in
SCD type swap is MODIFY_SYSTEM_DATA?. I think that some others SCD has
the same isn't it?
Permalink | Reply | 5 comments |
headers
Amon Ott | 12 Jan 2009 15:24

Re: About ACCESS_CONTROL and SUPERVISOR rights

Am Sünnavend 10 Januor 2009 schrieb Javier J. Martínez Cabezón:
> If I have one rol named gerency_r that admin the roles Technician_r,
> nurses_r and Doctor_r, Technician_r has write_only rights to
> patient_data_t type, Doctor_r has read-write access granted to it and
> nurses_r only read-only.
>  If secoff grants ACCESS_CONTROL right to patient_data to rol
> gerency_r then gerency_r could add or remove standard DAC rights
> access to all data from this type involving this three roles isn't it?

ACCESS_CONTROL is for granting normal RSBAC rights.

DAC rights would be MODIFY_PERMISSIONS_DATA and CHANGE_OWNER.

>  If secoff grants SUPERVISOR right to patient_data type to rol
> gerency_r then gerency_r could add or remove any RSBAC rights access
> to this type involving this three roles. Is this correct?

SUPERVISOR allows to set or revoke the RC special rights like ACCESS_CONTROL 
or SUPERVISOR itself.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 3 comments |
headers
Amon Ott | 12 Jan 2009 15:26

Re: About SCD T_swap.

Am Sünndag 11 Januor 2009 schrieb Javier J. Martínez Cabezón:
> Hi all, while looking some code of 1.3.7 rsbac version (swapfile.c)
> when you add one partition/file with swapon and swapoff it only checks
> that you own the capability CAP_SYS_ADMIN and if you have
> MODIFY_SYSTEM_DATA in SCD_swap and ADD_TO_KERNEL rights in the
> file/device to add. ADD_TO_KERNEL (and REMOVE_TO_KERNEL) to SCD_swap
> is ignored isn't it?. I'm wrong thinking that the only right useful in
> SCD type swap is MODIFY_SYSTEM_DATA?. I think that some others SCD has
> the same isn't it?

Most SCD targets only have checks for GET_STATUS_DATA (read) and 
MODIFY_SYSTEM_DATA (write settings). The special case is SCD other, which is 
used by some models (RC, ACL) to control access to NONE targets.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 3 comments |
headers
Amon Ott | 12 Jan 2009 15:32

RSBAC documentation

Hello again!

Some of you might have noticed that we have uploaded the 1.4.0 release to the 
Webserver. Before we make the big announcement there is still some work to do 
for the online documentation.

Please have a critical look at the RSBAC handbook, which you get through the 
Documentation link at rsbac.org. Are the texts consistent? Do they explain 
what you want to know about their topics?

We really want to make RSBAC easier to use with good documentation. So we 
always need people who can invest some hours per month on the documentation.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 6 comments |
headers
Javier J. Martínez Cabezón | 12 Jan 2009 15:42
Picon

Re: About ACCESS_CONTROL and SUPERVISOR rights

Thanks for your answers Amon. I think this part of the handbook that
explains the rc model is a bit confuse:

– ACCESS_CONTROL: Change normal (old) access rights to this type for
your administrated roles
– SUPERVISOR: Change these new special rights to this type for your
administrated roles.

Can  it be substitute by: ACCESS_CONTROL: Change none-security related
rsbac access rights to this type for your administrated roles.
-SUPERVISOR: Permits add or remove security rsbac related rights to
this type for your administrated roles.

At first I though MODIFY_PERMISSIONS_DATA and ACCESS_CONTROL were
redundant I was wrong seems.
2009/1/12 Amon Ott <ao <at> rsbac.org>:
> Am Sünnavend 10 Januor 2009 schrieb Javier J. Martínez Cabezón:
>> If I have one rol named gerency_r that admin the roles Technician_r,
>> nurses_r and Doctor_r, Technician_r has write_only rights to
>> patient_data_t type, Doctor_r has read-write access granted to it and
>> nurses_r only read-only.
>>  If secoff grants ACCESS_CONTROL right to patient_data to rol
>> gerency_r then gerency_r could add or remove standard DAC rights
>> access to all data from this type involving this three roles isn't it?
>
> ACCESS_CONTROL is for granting normal RSBAC rights.
>
> DAC rights would be MODIFY_PERMISSIONS_DATA and CHANGE_OWNER.
>
>>  If secoff grants SUPERVISOR right to patient_data type to rol
(Continue reading)

Permalink | Reply | 2 comments |

Gmane