Request for help .... system call entry pointes ...
by jagan kommineni
Hi,
In my projects, I am trapping basic system calls like open, read, write,
close etc ...
for creating POSIX interface semantics for remote file. I am using SOAP
protocol
to communicate with the remote foles.
http://www.csse.monash.edu.au/~jagan/research.htm
I rewrite functions such as open, read, write etc... as shown below and
I created a library module
and preloaded by using LD_PRELOAD environemnt variable.
---------------------------------------
for open call,
open, _open, __open, __libc_open, open64, _open64, __open64,
__libc_open64
for read call
read, _read, _read, __libc_read
for write call
write, _write, __write __libc_write etc .....
-------------------------------------------
It is working pefectly well with Redhat 7.3, but in the recent releases
of redhat 8 and 9.
I am not able to trap system calls, it seems there are some changes to
interfaces for enter
in to system calls. If any body have any idea about the new changes, I
will be glad to here.
my email addess: jagan(a)csse.monash.edu.au
with regards,
Jagan Kommineni
19 years, 10 months
What does 'plus' in ls -Z mean?
by Ling Li
Some files/directories have '+' when they are displayed with ls -Z. For example,
# ls -dZ /lost+found/
drwx------+ root root system_u:object_r:lost_found_t /lost+found/
What does the '+' after the mode 'rwx------' mean?
--Ling
19 years, 10 months
Re: Access to the postgresql data files
by Stephen Smalley
On Fri, 2004-06-04 at 08:15, Igor Borisovsky wrote:
> Hi.
> I have a question about selinux policy configuration for FC2.
> I need to forbid access to the postgresql data files from user root.
> I guess i have to create certain type for postgresql. Let's name this type
> pgsql.
> Thus i have something like that:
> [root selinux pgsql]# pwd
> /var/lib/pgsql
> [root selinux pgsql]# ls -aZ
> drwx------+ postgres postgres postgres:object_r:pgsql_home_dir_t .
> drwxr-xr-x root root system_u:object_r:var_lib_t ..
> drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t backups
> -rw------- postgres postgres postgres:object_r:pgsql_home_t .bash_history
> -rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t .bash_profile
> drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t data
> -rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t initdb.i18n
> drwxr-xr-x+ postgres postgres postgres:object_r:pgsql_home_t .mc
> [root selinux pgsql]#
> So far user root within sysadm_r role has access to the postgresql data
> files.
> I guess i need to find and revoke this permission from sysadm_r role.
> After looking at the policy.conf file I can't understand this.
> So how can i prevent access to postgresql data files from user root?
> Thanks.
Russell Coker already responded to your posting on the
fedora-selinux-list. I would only add a few comments:
1) If you truly want to start reducing the power of sysadm_t, then you
would start by disabling the unrestricted_admin and unlimitedServices
tunables in policy/tunable.te and make load. Otherwise, sysadm_t is
completely unconfined in the Fedora policy. Then you can remove direct
access by sysadm_t to your new types just by omitting the sysadmfile
attribute from the type declarations for your new types. But as Russell
noted, sysadm_t can easily get around such restrictions, so much more
work would be necessary to truly prevent access.
2) If you just want to prevent root from having such access, you could
remove sysadm_r from the authorized roles for root, as Russell noted. I
think that for SELinux play machines, people have authorized root for
only user_r and then authorized another user identity for staff_r and
sysadm_r. But in Fedora, I think you would also have to remove
pam_selinux from the /etc/pam.d/su configuration to achieve this goal,
so that your non-root user can su to uid 0 without having his SELinux
user identity changed to root. Otherwise, su will try to change the
SELinux user identity to root at the same time.
3) Do you really want to prevent someone with the root password from
having access to the database, or do you just want to prevent uid 0
processes from having access? A uid 0 process does not necessarily have
the SELinux root user identity; the SELinux user identity is only
assigned by particular programs such as login and sshd and is unaffected
by setuid programs.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
19 years, 10 months
Matlab and /var/tmp
by chris albert
Hi,
Upgraded FC1->FC2, installed selinux later, running in permissive mode,
debugging 'avc: denied' messages.
Matlab's license manager, called from an init script writes files in
/var/tmp and checks them periodically, including inside a subdirectory
/var/tmp/.flexlm, which it creates if necessary. The init script,
provided in the Matlab distro, asks you in comments to change the user
it runs under to an ordinary user, and the initrc_su_t transition works
fine for file creation in /var/tmp, as long as you dont have vestigal
files and directories there from before the selinux relabling. I noticed
also that other leftovers from rpm build processes were there, still
unlabelled after the move to selinux.
I'm wondering if I missed something, or would it be a good idea to have
'fixfiles relable' flush /var/tmp in the same way it does /tmp.
Chris
19 years, 10 months
Runaway .* globs in file_contexts/types.fc
by Valdis.Kletnieks＠vt.edu
OK.. Maybe 3rd time's the charm ;)
Running Fedora Core as of last night-ish -devel tree, and installing
selinux-policy-strict-1.13.2-4.
Spotted while doing the relabelling (I knew there was a reason I try to
rememer to run it with '-v' ;):
/usr/sbin/setfiles: relabeling /usr/local/lib/xemacs/xemacs-packages/pkginfo/MANIFEST.sounds-au from root:object_r:lib_t to system_u:object_r:shlib_t
/usr/sbin/setfiles: relabeling /usr/local/lib/xemacs/xemacs-packages/pkginfo/MANIFEST.sounds-wav from root:object_r:lib_t to system_u:object_r:shlib_t
Looks like a runaway glob on '.*\.so'... Whoops. ;)
First, the good news.. ;)
Some grepping through file_contexts/file_contexts indicates that of the 553
uses of a .* glob, almost all are using it to indicate "to end of filename"
with either "/some/path.*" (197 usages) or "/some/path(/.*)?" (313 usages).
(Somebody else can audit these 510 to determine if The Other Flavor should have
been specified to handle the case of a file called "/some/path-foo" ;)
Now, the bad news.. There's 43 cases of "neither of the above" ;)
To find the rest:
grep '\.\*' file_contexts/file_contexts | egrep -v '\(\/\.\*\)\?[[:space:]]|\.\*[[:space:]]'
These 4 mystified me - why "(.*)?" instead of ".*" or "(/.*)?"
/var/run/courier(.*)? system_u:object_r:courier_var_run_t
/usr/lib(64)?/cyrus-imapd/(.*)? -- system_u:object_r:bin_t
/var/www/lrrd(.*)? system_u:object_r:lrrd_var_lib_t
/usr/X11R6/lib(64)?/xscreensaver(.*)? system_u:object_r:bin_t
I suspect that all 4 were intended to be of the form "foo(/.*)?" - anybody
know for sure?
Also, anybody know where these come from?
/lib(64)?/lvm-10(/.*) system_u:object_r:lvm_exec_t
/lib(64)?/lvm-200(/.*) system_u:object_r:lvm_exec_t
(I have some /lib/liblvm-10* files, but not /lib/lvm-* - is that from a
non-Fedora system? I'm not seeing a /lib/lvm-* file in either the lvm or lvm2
Fedora RPMs)
Now, some more good news - close to half the remaining 43 are from types.fc
handling of ld_so_t and shlib_t - patch to clean those up attached. ;)
Please double-check - I've verified that this patch doesn't unintentionally
relabel anything on my system, and does avoid mislabeling the two xemacs files,
but there very well might be things that intend to use .* to greedily swallow
across a / character for the types I changed.. if it's too drastic, probably
95% of the benefit could be gained by just changing all the \.so.*
to be \.so(\.[^/]*)* instead...
As an aside, I *tried* to do this against a current Fedora:
for i in *.rpm; do rpm -qpl $i >> /tmp/allfiles; done
sort -u /tmp/allfiles | /usr/sbin/setfiles -v -d -n -s file_contexts/file_contexts
but that just throws a lot of "File not found" for any files in RPMs that
aren't on my system. Could we have a -t (for "test") flag that reports "What
would the file context be set to if the file existed?" that skips statting the
file? It would make automated regression testing of this sort of thing a lot easier.
--- file_contexts/types.fc.dist 2004-06-01 21:09:03.000000000 -0400
+++ file_contexts/types.fc 2004-06-03 00:20:41.899373306 -0400
@@ -85,8 +85,8 @@
/var/ftp/bin(/.*)? system_u:object_r:bin_t
/var/ftp/bin/ls -- system_u:object_r:ls_exec_t
/var/ftp/lib(64)?(/.*)? system_u:object_r:lib_t
-/var/ftp/lib(64)?/ld.*\.so.* -- system_u:object_r:ld_so_t
-/var/ftp/lib(64)?/lib.*\.so.* -- system_u:object_r:shlib_t
+/var/ftp/lib(64)?/ld[^/]*\.so(\.[^/]*)* -- system_u:object_r:ld_so_t
+/var/ftp/lib(64)?/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
/var/ftp/etc(/.*)? system_u:object_r:etc_t
#
@@ -258,13 +258,13 @@
# /lib(64)?
#
/lib(64)?(/.*)? system_u:object_r:lib_t
-/lib(64)?/ld.*\.so.* -- system_u:object_r:ld_so_t
-/lib(64)?/tls/ld.*\.so.* -- system_u:object_r:ld_so_t
-/lib(64)?/lib.*\.so.* -- system_u:object_r:shlib_t
-/lib(64)?/[^/]*/lib.*\.so.* -- system_u:object_r:shlib_t
-/lib(64)?/devfsd/.*\.so.* -- system_u:object_r:shlib_t
-/lib(64)?/security/.*\.so.* -- system_u:object_r:shlib_t
-/lib(64)?/tls/i686/cmov/.*\.so.* -- system_u:object_r:shlib_t
+/lib(64)?/ld[^/]*\.so(\.[^/]*)* -- system_u:object_r:ld_so_t
+/lib(64)?/tls/ld[^/]*\.so(\.[^/]*)* -- system_u:object_r:ld_so_t
+/lib(64)?/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
+/lib(64)?/[^/]*/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
+/lib(64)?/devfsd/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
+/lib(64)?/security/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
+/lib(64)?/tls/i686/cmov/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
#
# /sbin
@@ -299,9 +299,9 @@
# /usr/lib(64)?
#
/usr/lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/lib(64)?/lib.*\.so.* -- system_u:object_r:shlib_t
+/usr/lib(64)?/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
/usr/lib(64)?/python.*\.so -- system_u:object_r:shlib_t
-/usr/lib(64)?/.*/lib[^/]*\.so.* -- system_u:object_r:shlib_t
+/usr/lib(64)?/.*/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
/usr/lib(64)?/.*/.*\.so -- system_u:object_r:shlib_t
/usr/lib(64)?/autofs/.*\.so -- system_u:object_r:shlib_t
/usr/lib(64)?/perl5/man(/.*)? system_u:object_r:man_t
@@ -316,21 +316,21 @@
# /usr/.*glibc.*-linux/lib(64)?
#
/usr/.*glibc.*-linux/lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/.*glibc.*-linux/lib(64)?/ld.*\.so.* system_u:object_r:ld_so_t
-/usr/.*glibc.*-linux/lib(64)?/lib.*\.so.* system_u:object_r:shlib_t
+/usr/.*glibc.*-linux/lib(64)?/ld[^/]*\.so(\.[^/]*)* system_u:object_r:ld_so_t
+/usr/.*glibc.*-linux/lib(64)?/lib[^/]*\.so(\.[^/]*)* system_u:object_r:shlib_t
# /usr/.*redhat-linux/lib(64)?
#
/usr/.*redhat-linux/lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/.*redhat-linux/lib(64)?/ld.*\.so.* system_u:object_r:ld_so_t
-/usr/.*redhat-linux/lib(64)?/lib.*\.so.* system_u:object_r:shlib_t
+/usr/.*redhat-linux/lib(64)?/ld[^/]*\.so(\.[^/]*)* system_u:object_r:ld_so_t
+/usr/.*redhat-linux/lib(64)?/lib[^/]*\.so(\.[^/]*)* system_u:object_r:shlib_t
#
# /usr/.*linux-libc.*/lib(64)?
#
/usr/.*linux-libc.*/lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/.*linux-libc.*/lib(64)?/ld.*\.so.* system_u:object_r:ld_so_t
-/usr/.*linux-libc.*/lib(64)?/lib.*\.so.* system_u:object_r:shlib_t
+/usr/.*linux-libc.*/lib(64)?/ld[^/]*\.so(\.[^/]*)* system_u:object_r:ld_so_t
+/usr/.*linux-libc.*/lib(64)?/lib[^/]*\.so(\.[^/]*)* system_u:object_r:shlib_t
#
# /usr/local
@@ -349,7 +349,7 @@
# /usr/local/lib(64)?
#
/usr/local/lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/local/lib(64)?/.*\.so.* -- system_u:object_r:shlib_t
+/usr/local/lib(64)?(/.*)+\.so(\.[^/]*)* -- system_u:object_r:shlib_t
#
# /usr/sbin
@@ -365,7 +365,7 @@
# /usr/X11R6/(.*/)?lib(64)?
#
/usr/X11R6/(.*/)?lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/X11R6/(.*/)?lib(64)?/.*\.so.* -- system_u:object_r:shlib_t
+/usr/X11R6/(.*/)?lib(64)?(/.*)+\.so(\.[^/]*)* -- system_u:object_r:shlib_t
#
# /usr/X11R6/man
@@ -378,7 +378,7 @@
/usr/kerberos/bin(/.*)? system_u:object_r:bin_t
/usr/kerberos/sbin(/.*)? system_u:object_r:sbin_t
/usr/kerberos/lib(64)?(/.*)? system_u:object_r:lib_t
-/usr/kerberos/lib(64)?/lib.*\.so.* -- system_u:object_r:shlib_t
+/usr/kerberos/lib(64)?/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
#
# Fonts dir
@@ -459,7 +459,7 @@
#
/usr/java/j2sdk.*/bin(/.*)? system_u:object_r:bin_t
/usr/java/j2sdk.*/jre/lib(64)?/i386(/.*)? system_u:object_r:lib_t
-/usr/java/j2re1.*/plugin/i386(/.*)?/lib.*\.so.* -- system_u:object_r:shlib_t
+/usr/java/j2re1.*/plugin/i386(/.*)?/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
#
# The krb5.conf file is always being tested for writability, so
19 years, 10 months
Turn on SELinux
by Khurt Williams
I installed Fedora Core 2. I did not enable selinux at install. How
do I now enable it?
19 years, 10 months
kernel install issue: /sbin/depmod - avc's supplied
by Tom London
I'm presuming this is a know issue, but just in case....
kernel installs (via 'yum update') when running in strict/enforcing fail.
Now that I have kernel-2.6.6-1.421 installed and running, I have avc's
from /var/log/messages. Here are just a few:
Jun 4 14:03:16 dell kernel: audit(1086382996.206:0): avc: denied
{ read } for pid=3643 exe=/sbin/depmod name=toshiba.ko dev=hdb3
ino=1056054 scontext=root:sysadm_r:depmod_t
tcontext=system_u:object_r:lib_t tclass=file
Jun 4 14:03:16 dell kernel: audit(1086382996.206:0): avc: denied
{ read } for pid=3643 exe=/sbin/depmod name=ppdev.ko dev=hdb3
ino=1056048 scontext=root:sysadm_r:depmod_t
tcontext=system_u:object_r:lib_t tclass=file
Jun 4 14:03:16 dell kernel: audit(1086382996.207:0): avc: denied
{ read } for pid=3643 exe=/sbin/depmod name=edd.ko dev=hdb3 ino=1069944
scontext=root:sysadm_r:depmod_t tcontext=system_u:object_r:lib_t tclass=file
Jun 4 14:03:16 dell kernel: audit(1086382996.207:0): avc: denied
{ getattr } for pid=3643 exe=/sbin/depmod
path=/lib/modules/2.6.6-1.422/build/sound/oss/dmasound/Makefile dev=hdb3
ino=1036012 scontext=root:sysadm_r:depmod_t
tcontext=system_u:object_r:lib_t tclass=file
Jun 4 14:03:16 dell kernel: audit(1086382996.208:0): avc: denied
{ getattr } for pid=3643 exe=/sbin/depmod
path=/lib/modules/2.6.6-1.422/build/sound/oss/dmasound/Kconfig dev=hdb3
ino=1036011 scontext=root:sysadm_r:depmod_t
tcontext=system_u:object_r:lib_t tclass=file
Jun 4 14:03:16 dell kernel: audit(1086382996.208:0): avc: denied
{ getattr } for pid=3643 exe=/sbin/depmod
path=/lib/modules/2.6.6-1.422/build/sound/oss/Makefile dev=hdb3
ino=1036006 scontext=root:sysadm_r:depmod_t
tcontext=system_u:object_r:lib_t tclass=file
The contexts in the rpm appear correct (i.e., most are
system_u:object_r:modules_object_t, or similar), but the files in
/lib/modules/2.6.6-1.422/.... are all labeled system_u:object_r:lib_t.
Anyway, /sbin/depmod is having a hell of a time.
Thanks to Stephen, the workaround of going into permissive mode prior to
'yum update' seems to work, but the file contexts need fixing.
I checked bugzilla for yum but didn't find anything. Has this been
filed/fixed?
tom
19 years, 10 months
Re: Install of latest packages....kernel-2.6.6-1.421 fails, selinux-policy-strict-1.13.3-2 succeeds
by Tom London
Stephen,
That did it! Thanks! (You saved me a lot of time, since I usually don't
check
fedora-devel-list. I guess I should!)
I needed to use 'single enforcing=0' to do the 'fixfiles relabel'. Lots
needed relabeling (much in /lib/modules/2.6.6-1.421/).
kernel-2.6.6-1.421 turns avc messages back on!
tom
------------------------------------------------------------------------
* /From/: Stephen Smalley <sds epoch ncsc mil>
------------------------------------------------------------------------
On Fri, 2004-06-04 at 14:06, Tom London wrote:
> My previous workaround (do 'setenforce 0; yum ....' followed by a
> relabel) did not work this time. The mkinitrd now fails even under
> permissive mode:
> kernel 100 % done 1/1
> memlock: Cannot allocate memory
> Couldn't lock into memory, exiting.
> mkinitrd failed
Also reported on fedora-devel-list; I don't think it is
SELinux-related. 'ulimit -l unlimited' to workaround until a new kernel
is available.
--
Stephen Smalley <sds epoch ncsc mil>
National Security Agency
19 years, 10 months
Install of latest packages....kernel-2.6.6-1.421 fails, selinux-policy-strict-1.13.3-2 succeeds
by Tom London
I did a 'yum update' to pick up the latest stuff from the development
and Arjan's tree. I worked around the rpm conflicts from early stuff in
the development tree.
The kernel update (421) still fails under strict/enforcing mode. The
context labels now appear to be in the rpm file, but I'm getting similar
messages:
...... lots and lots of WARNING messages like:
WARNING: Couldn't stat
/lib/modules/2.6.6-1.421/build/include/asm-i386/ptrace.h: Permission denied
WARNING: Couldn't stat
/lib/modules/2.6.6-1.421/build/include/asm-i386/bug.h: Permission denied
WARNING: Couldn't stat
/lib/modules/2.6.6-1.421/build/include/asm-i386/serial.h: Permission denied
WARNING: Couldn't stat /lib/modules/2.6.6-1.421/build/mm/Makefile:
Permission denied
FATAL: Could not open /lib/modules/2.6.6-1.421/modules.dep.temp for
writing: Permission denied
/bin/bash: /root/.bashrc: Permission denied
No dep file found for kernel 2.6.6-1.421
mkinitrd failed
My previous workaround (do 'setenforce 0; yum ....' followed by a
relabel) did not work this time. The mkinitrd now fails even under
permissive mode:
[root@dell selinux]# setenforce 0
[root@dell selinux]# yum install kernel
Gathering header information file(s) from server(s)
Server: Test Linux 2.6-test prerelease kernels
Server: Fedora Core 2 - i386 - Base
Server: Fedora Core 2 - Development Tree
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Resolving dependencies
Dependencies resolved
I will do the following:
[install: kernel 2.6.6-1.421.i686]
Is this ok [y/N]: y
Downloading Packages
Running test transaction:
Test transaction complete, Success!
kernel 100 % done 1/1
memlock: Cannot allocate memory
Couldn't lock into memory, exiting.
mkinitrd failed
Since the latest kernel's seemed to have auditing off, I can't locate
anything interesting in /var/log/messages. (Looks like CONFIG_AUDIT is
set to y in 421.)
Since the label now appear correct in the rpm file, could this be
something in the policy/context files? Any ideas?
The install of the 1.13.3-2 policy packages seemed to work OK. It left
my /etc/selinux/config file untouched. (I guess I should have removed it
prior to install.....sorry).
tom
19 years, 10 months
