selinux AVC errors despite making a rule :(

Okay I got a server running FC6 and Plesk 8.1.1 running websites.

I do a :
grep avc /var/log/messages
to see any policies need tweaking.

I get:
Jun 28 23:29:18 server kernel: audit(1183073358.302:2368: avc: denied {
link } for pid=8544 comm="in.proftpd"
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key

every single minute. Now I started a webcam that FTPs into the server
every minute. So I thought no biggy, its in.proftpd, lets make a policy:

grep proftpd /var/log/messages | audit2allow -M proftpd
selinux -i proftpd.pp

okay but i STILL get these errors every minute...

Can someone please help me?

Thanks!

Re: selinux AVC errors despite making a rule :(

David Cottle wrote:
> Okay I got a server running FC6 and Plesk 8.1.1 running websites.
>
> I do a :
> grep avc /var/log/messages
> to see any policies need tweaking.
>
> I get:
> Jun 28 23:29:18 server kernel: audit(1183073358.302:2368: avc: denied {
> link } for pid=8544 comm="in.proftpd"
> scontext=system_u:system_r:ftpd_t:s0
> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
>
> every single minute. Now I started a webcam that FTPs into the server
> every minute. So I thought no biggy, its in.proftpd, lets make a policy:
>
> grep proftpd /var/log/messages | audit2allow -M proftpd
> selinux -i proftpd.pp
>
> okay but i STILL get these errors every minute...
>
> Can someone please help me?
>   

Run audit2why on the denial and see where the denial is coming from, I 
suspect it is because of the MLS constraints in which case you need to 
figure out why they are in different levels or make ftpd_t a trusted mls 
subject.

selinux performance

apcupsd policy addon

debian stores the apcupsd binary under /sbin not /usr/sbin

--- /usr/src/refpolicy-20070629/policy/modules/services/ 
apcupsd.fc      2007-05-07 16:55:54.000000000 +0200
+++ policy/modules/services/apcupsd.fc  2007-07-01 10:18:45.000000000  
+0200
 <at>  <at>  -1,4 +1,5  <at>  <at> 
/usr/sbin/apcupsd              --      gen_context 
(system_u:object_r:apcupsd_exec_t,s0)
+/sbin/apcupsd                  --      gen_context 
(system_u:object_r:apcupsd_exec_t,s0)
/var/log/apcupsd\.events.*     --      gen_context 
(system_u:object_r:apcupsd_log_t,s0)

[ANN] SE-PostgreSQL 1.0 Beta released

Hi,

We released the beta version of SE-PostgreSQL and the first
official documentation at Jul 01 2007.

The purpose of the version is to improve its quality, like bugfix.
The SE-PostgreSQL development team welcomes any feedback from open
source community, like your comments or opinions, bug-reporting,
and so on.

Thanks,

============================================================
SE-PostgreSQL 1.0 Beta version Released
============================================================

SE-PostgreSQL development team released SE-PostgreSQL 1.0 beta
version and "The security guide of Security-Enhanced PostgreSQL
beta edition (Japanese/English)" at Jul 01 2007.

You can get those packages from the following URL:
 http://code.google.com/p/sepgsql/downloads/list

o SE-PostgreSQL 1.0 beta version
 sepostgresql-8.2.4-0.391.beta.fc6.i386.rpm
 sepostgresql-8.2.4-0.391.beta.fc7.i386.rpm
 sepostgresql-8.2.4-0.391.beta.fc7.src.rpm
 sepostgresql-8.2.4-0.391.beta.fc7.patch
o The base security policy for Fedora 7
 selinux-policy-2.6.4-14.sepgsql.fc7.noarch.rpm
 selinux-policy-targeted-2.6.4-14.sepgsql.fc7.noarch.rpm
 selinux-policy-devel-2.6.4-14.sepgsql.fc7.noarch.rpm
o The base security policy for Fedora core 6
 selinux-policy-2.4.6-74.sepgsql.fc6.noarch.rpm
 selinux-policy-targeted-2.4.6-74.sepgsql.fc6.noarch.rpm
 selinux-policy-devel-2.4.6-74.sepgsql.fc6.noarch.rpm
o "The security guide of Security-Enhanced PostgreSQL" beta edition
 sepgsql_security_guide.20070701.jp.beta.pdf (Japanese)
 sepgsql_security_guide.20070701.en.beta.pdf (English)

See the following URL, for details of installation.
o SE-PostgreSQL installation memo (Fedora 7)
 http://code.google.com/p/sepgsql/wiki/install_memo_Fedora7
o SE-PostgreSQL installation memo (Fedora core 6)
 http://code.google.com/p/sepgsql/wiki/install_memo_FC6

The features of SE-PostgreSQL
-----------------------------
Security Enhanced PostgreSQL (SE-PostgreSQL) is a security extension
built in PostgreSQL. It enables to administrate operating system and
database management system under the unified security policy by
cooperation with SELinux.
In addition, it also provides fine-grained access control including
column and row level, and mandatory access control being non-bypassable,
even if privileged database user.

Those features enables to build a database management system into
information flow control scheme integrated with operating system,
and to protect our information asset from threats like manipulation
or leaking.

The purpose of this version
---------------------------
The purpose of this version is evaluation and test for the stable
SE-PostgreSQL 1.0 release. Therefore, we don't recommends to apply
this version for test/evaluation purpose.
SE-PostgreSQL development team also declares the feature freeze for
the stable SE-PostgreSQL 1.0. It means that we have no plan to add
any feature except for bug fixes until it is released.
We always welcome any feedback from open source community, such as
bug reporting, question for SE-PostgreSQL and documentation.

Roadmap
-------
SE-PostgreSQL development team have a plan to release the stable
SE-PostgreSQL 1.0 after one month's evaluation.
In the future, we continue our activity to merge PGACE/SE-PostgreSQL
features into the upstreamed PostgreSQL.

Changes since SE-PostgreSQL 1.0 alpha
-------------------------------------
The following remarkable changes are applied from SE-PostgreSQL 1.0
alpha released at May 05 2007.

o Applying PGACE framework
 PostgreSQL Access Control Extension (PGACE) is a framework consist
 of many hooks and a mechanism to associate a security attribute with
 database objects, to provide a common infrastructure for multiple
 security extensions built in PostgreSQL.
o backup/restore utility
 '--enable-security' option was added for pg_dump and pg_dumpall commands.
 It enables to backup and restore database with security context.
o Extended SQL statement
 Extensions of CREATE TABLE/FUNCTION/DATABASE and ALTER TABLE/FUNCTION/DATABASE
 statements enables to configure security context of database object without
 modifying system catalog directly.
o Adding new permissions
 {use} permission was added for table, column and tuple object classes.
 It is evaluated in the case when a column is accessed without reading its
 contents such as use on WHERE or GROUP BY clause.
o Improve security policy
 Two new types are defined.
 One is sepgsql_ro_table_t for read-only tables. The other is sepgsql_fixed_table_t
 for non-manipulatable tables. A type of 'sepgsql_user_proc_t' is attached for
 user defined SQL function. Administrative domain cannot execute a function with this
 type, so we can avoid to execute untrusted functions with unconfined authorities.

Fixed many bugs
---------------
 We found and fixed many bugs for four months since alpha release on this March.

Acknowledgment
--------------
 The development of SE-PostgreSQL is supported by Exploratory Software Project,
 IPA(Information-technology Promotion Agency, Japan).

Thanks,
--

-- 
KaiGai Kohei <kaigai@...>

Re: selinux performance

On Sun, 1 Jul 2007, somayeh afzali wrote:

> hi,
> 
> is there a tool for checking selinux performance?

avcstat can help

--

-- 
James Morris
<jmorris@...>

GPLv3

What are we going to do regarding GPLv3?

The NSA code has no copyright (being produced by the US government) and the 
majority of other code included in the SE Linux policy and utilities comes 
from a small number of sources.  Getting agreement to relicense the source 
under GPLv3 should not be that difficult (if Tresys, Red Hat, and IBM agree 
then we're almost there).

I think that the patent clauses in GPLv3 have some potential to avoid problems 
in future, and if nothing else will be good PR.

I would like to relicense my code under GPLv3.  Anyone who wants to use any of 
my SE Linux related code under GPLv3 can do so.  Of course this doesn't give 
any real benefit unless others join in.

--

-- 
russell@...
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

Re: [patch 1/3] libsemanage: genhomedircon replacement

Eamon Walsh wrote:
> Karl MacMillan wrote:
>> On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
>>> Karl MacMillan wrote:
>>>> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
>>>>
>>>>>   I'm not a fan of the Python dependencies.
>>>>>
>>>> Why?
>>> Here's a nice example of RPM hell, courtesy of our Python 
>>> dependency.  I got this earlier in the year on one of my machines.
>>>
>>>
>>> # yum -y upgrade
>>> --> Running transaction check
>>> --> Processing Dependency: gnutls-devel for package: libsoup-devel
>>> --> Processing Dependency: python(abi) = 2.4 for package: 
>>> audit-libs-python
>>> --> Restarting Dependency Resolution with new changes.
>>> --> Populating transaction set with selected packages. Please wait.
>>> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
>>> --> Running transaction check
>>> --> Processing Dependency: python(abi) = 2.4 for package: 
>>> audit-libs-python
>>> --> Finished Dependency Resolution
>>> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
>>> audit-libs-python
>>>
>>
>> Rawhide or a release? Was this during the move to 2.5?
> 
> It was upgrading across the 2.4/2.5 switch, not rawhide as I recall.  To 
> answer James, this was just an example of a problem I ran into; I don't 
> have any specific problems with the bindings.
> 
>>
>> Larger issue, though, is that any dependency could cause the same
>> problem. I'm not convinced that what was likely a packaging error or yum
>> error should prevent us from using the best tools for the job.
>>
>> Again: I'm not totally against this. I'm just very concerned about the
>> potential for problems in this code and the initial implementation
>> confirmed all of those concerns. Is it possible to get this code correct
>> in C? Sure. Is it likely for it to be correct initially and stay that
>> way is the question.
>>
>> Can I suggest a middle ground? Implement in C (or C++) but use a string
>> library.
> 
> A library would be great, I'm still depressed about glib's 
> abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
> possible library that could be used.
> 
> 

Unfortunately ustr isn't in yum so we'd have to pull code into the lib 
itself, which I'd prefer not to. Additionally ustr's documentation is a 
bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
function does nothing." in the docs is a bit disconcerting as well.

Re: [patch 1/3] libsemanage: genhomedircon replacement

On Mon, 2007-07-02 at 10:00 -0400, Joshua Brindle wrote:
> Eamon Walsh wrote:
> > Karl MacMillan wrote:
> >> On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
> >>> Karl MacMillan wrote:
> >>>> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> >>>>
> >>>>>   I'm not a fan of the Python dependencies.
> >>>>>
> >>>> Why?
> >>> Here's a nice example of RPM hell, courtesy of our Python 
> >>> dependency.  I got this earlier in the year on one of my machines.
> >>>
> >>>
> >>> # yum -y upgrade
> >>> --> Running transaction check
> >>> --> Processing Dependency: gnutls-devel for package: libsoup-devel
> >>> --> Processing Dependency: python(abi) = 2.4 for package: 
> >>> audit-libs-python
> >>> --> Restarting Dependency Resolution with new changes.
> >>> --> Populating transaction set with selected packages. Please wait.
> >>> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
> >>> --> Running transaction check
> >>> --> Processing Dependency: python(abi) = 2.4 for package: 
> >>> audit-libs-python
> >>> --> Finished Dependency Resolution
> >>> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
> >>> audit-libs-python
> >>>
> >>
> >> Rawhide or a release? Was this during the move to 2.5?
> > 
> > It was upgrading across the 2.4/2.5 switch, not rawhide as I recall.  To 
> > answer James, this was just an example of a problem I ran into; I don't 
> > have any specific problems with the bindings.
> > 
> >>
> >> Larger issue, though, is that any dependency could cause the same
> >> problem. I'm not convinced that what was likely a packaging error or yum
> >> error should prevent us from using the best tools for the job.
> >>
> >> Again: I'm not totally against this. I'm just very concerned about the
> >> potential for problems in this code and the initial implementation
> >> confirmed all of those concerns. Is it possible to get this code correct
> >> in C? Sure. Is it likely for it to be correct initially and stay that
> >> way is the question.
> >>
> >> Can I suggest a middle ground? Implement in C (or C++) but use a string
> >> library.
> > 
> > A library would be great, I'm still depressed about glib's 
> > abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
> > possible library that could be used.
> > 
> > 
> 
> Unfortunately ustr isn't in yum so we'd have to pull code into the lib 
> itself, which I'd prefer not to.

Ustr is intended to be pulled into projects - that's why it is a single
file.

>  Additionally ustr's documentation is a 
> bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
> function does nothing." in the docs is a bit disconcerting as well.
> 

I'm certain James can answer any questions.

More to the point - what do you think of using some string library?

Karl

Re: GPLv3

On Mon, 2007-07-02 at 19:29 +1000, Russell Coker wrote:
> What are we going to do regarding GPLv3?
> 
> The NSA code has no copyright (being produced by the US government) and the 
> majority of other code included in the SE Linux policy and utilities comes 
> from a small number of sources.  Getting agreement to relicense the source 
> under GPLv3 should not be that difficult (if Tresys, Red Hat, and IBM agree 
> then we're almost there).
> 
> I think that the patent clauses in GPLv3 have some potential to avoid problems 
> in future, and if nothing else will be good PR.
> 
> I would like to relicense my code under GPLv3.  Anyone who wants to use any of 
> my SE Linux related code under GPLv3 can do so.  Of course this doesn't give 
> any real benefit unless others join in.
> 

I think it is too soon to do this. The FSF is still preparing documents
on how best to transition to the v3 and I think it is going to take a
while for corporations to digest the changes.

I'd rather wait to consider this as I don't believe there is any real
benefit from us being an early adopter. Most importantly, I want to see
how the v2/v3 incompatibilities are handled by other projects.

Karl