Re: WARNING in apparmor_secid_to_secctx

[Russell Coker via Selinux]

On Tuesday, 4 September 2018 10:57:15 PM AEST Stephen Smalley wrote:
> > I installed the tools, and we started loading policy.
> > But then it turned out that wheezy policy does not allows mounting
> > cgroup2 fs and maybe some others even in non-enforcing mode. As far as
> > I understand that's because the policy does not have definition for
> > the fs, and so loading bails out with an error.

The aim has always been with SE Linux in Debian that the policy will support 
the kernel from the next release and from the previous release.  Much of this 
comes from upstream, but sometimes we have to go out of our way to get it.  
Sometimes if you want to run unusual combinations of kernel and OS Debian 
doesn't get a backport of the policy to support it in which case I often have 
a special policy on my site to do it.

It seems strange that you wouldn't be able to mount a filesystem in permissive 
mode.  Which program was trying to mount it?  Was it systemd?  It might be a 
systemd bug.

> > We need cgroup2 both for testing and for better sandboxing (no other
> > way to restrict e.g. memory consumption). Moreover, we did not test
> > any actual interesting interactions with selinux (there must be some?
> > but I don't know what are they).
> > So I had to uninstall the tool and policy is not loaded again.
> > I investigated building a newer debian image with debootstrap (which
> > should have newer policy I guess). But they don't work, some cryptic
> > errors in init. Other people reported the same.
> > So that's we are. I don't have any ideas left...

It would be nice to know what the errors are.  Although we aren't really 
interested in bug reports from Wheezy, Stretch is the current stable release.
 
> So why not ask for help from the SELinux community?  I've cc'd the
> selinux list and a couple of folks involved in Debian selinux.  I see a
> couple of options but I don't know your constraints for syzbot:
> 
> 1) Run an instance of syzbot on a distro that supports SELinux enabled
> out of the box like Fedora. Then you don't have to fight with SELinux
> and can just focus on syzbot, while still testing SELinux enabled and
> enforcing.
> 
> 2) Report the problems you are having with enabling SELinux on newer
> Debian to the selinux list and/or the Debian selinux package maintainers
> so that someone can help you resolve them.
> 
> 3) Back-port the cgroup2 policy definitions to your wheezy policy,
> rebuild it, and install that.  We could help provide guidance on that.
> I think you'll need to rebuild the base policy on wheezy; in
> distributions with modern SELinux userspace, one could do it just by
> adding a CIL module locally.

I could backport that myself and put the package on my apt repository.  Tell 
me what version of the kernel you are using and I'll have a look at it.

> As for exercising SELinux, you'll exercise SELinux just by enabling it
> and loading a policy, since it will perform permission checking on all
> object accesses.   But you can get more extensive coverage by running
> the selinux-testsuite.  We only test that on Fedora and RHEL however, so
> getting it to work on Debian might take some effort.


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: BTRFS losing SE Linux labels on power failure or "reboot -nffd"

[Russell Coker via Selinux]

https://www.spinics.net/lists/linux-btrfs/msg77927.html

Thanks to Hans van Kranenburg and Holger Hoffstätte, the above has the link to 
a message with the patch for this which was already included in kernel 4.16.11 
which was uploaded to Debian on the 27th of May and got into testing about the 
time that my message got to the SE Linux list.

The kernel from Debian/Stable still has the issue.  So using a testing kernel 
might be a good option to deal with this problem at the moment.

On Monday, 4 June 2018 11:14:52 PM AEST Russell Coker wrote:
> The command "reboot -nffd" (kernel reboot without flushing kernel buffers or
> writing status) when run on a BTRFS system with SE Linux will often result
> in /var/log/audit/audit.log being unlabeled.  It also results in some
> systemd- journald files like
> /var/log/journal/c195779d29154ed8bcb4e8444c4a1728/ system.journal being
> unlabeled but that is rarer.  I think that the same problem afflicts both
> systemd-journald and auditd but it's a race condition that on my systems
> (both production and test) is more likely to affect auditd.
> 
> root@stretch:/# xattr -l /var/log/audit/audit.log
> security.selinux:
>    73 79 73 74 65 6D 5F 75 3A 6F 62 6A 65 63 74 5Fsystem_u:object_
> 0010   72 3A 61 75 64 69 74 64 5F 6C 6F 67 5F 74 3A 73r:auditd_log_t:s
> 0020   30 00  0.
> 
> SE Linux uses the xattr "security.selinux", you can see what it's doing with
> xattr(1) but generally using "ls -Z" is easiest.
> 
> If this issue just affected "reboot -nffd" then a solution might be to just
> not run that command.  However this affects systems after a power outage.
> 
> I have reproduced this bug with kernel 4.9.0-6-amd64 (the latest security
> update for Debian/Stretch which is the latest supported release of Debian). 
> I have also reproduced it in an identical manner with kernel 4.16.0-1-amd64
> (the latest from Debian/Unstable).  For testing I reproduced this with a 4G
> filesystem in a VM, but in production it has happened on BTRFS RAID-1
> arrays, both SSD and HDD.
> 
> #!/bin/bash
> set -e
> COUNT=$(ps aux|grep [s]bin/auditd|wc -l)
> date
> if [ "$COUNT" = "1" ]; then
>  echo "all good"
> else
>  echo "failed"
>  exit 1
> fi
> 
> Firstly the above is the script /usr/local/sbin/testit, I test for auditd
> running because it aborts if the context on it's log file is wrong.  When SE
> Linux is in enforcing mode an incorrect/missing label on the audit.log file
> causes auditd to abort.
> 
> root@stretch:~# ls -liZ /var/log/audit/audit.log
> 37952 -rw---. 1 root root system_u:object_r:auditd_log_t:s0 4385230 Jun 
> 1 12:23 /var/log/audit/audit.log
> Above is before I do the tests.
> 
> while ssh stretch /usr/local/sbin/testit ; do
>  ssh btrfs-local "reboot -nffd" > /dev/null 2>&1 &
>  sleep 20
> done
> Above is the shell code I run to do the tests.  Note that the VM in question
> runs on SSD storage which is why it can consistently boot in less than 20
> seconds.
> 
> Fri  1 Jun 12:26:13 UTC 2018
> all good
> Fri  1 Jun 12:26:33 UTC 2018
> failed
> Above is the output from the shell code in question.  After the first reboot
> it fails.  The probability of failure on my test system is greater than
> 50%.
> 
> root@stretch:~# ls -liZ /var/log/audit/audit.log
> 37952 -rw---. 1 root root system_u:object_r:unlabeled_t:s0 4396803 Jun 
> 1 12:26 /var/log/audit/audit.log
> Now the result.  Note that the Inode has not changed.  I could understand a
> newly created file missing an xattr, but this is an existing file which
> shouldn't have had it's xattr changed.  But somehow it gets corrupted.
> 
> The first possibility I considered was that SE Linux code might be at fault.
> I asked on the SE Linux mailing list (I haven't been involved in SE Linux
> kernel code for about 15 years) and was informed that this isn't likely at
> all.  There have been no problems like this reported with other
> filesystems.
> 
> Does anyone have any ideas of other tests I should run?  Anyone want me to
> try a different kernel?  I can give root on a VM to anyone who wants to
> poke at it.


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/





___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: BTRFS losing SE Linux labels on power failure or "reboot -nffd".

[Russell Coker via Selinux]

On Sunday, 3 June 2018 4:18:09 AM AEST Nick Kralevich wrote:
> Does BTRFS have the equivalent of an fsck command which is run on
> boot? I've seen similar problems before where fsck tries fixing up the
> filesystem after an unclean shutdown, and the SELinux labels aren't
> properly handled by the fsck program.

https://en.wikipedia.org/wiki/Btrfs

BTRFS is designed to be self-healing and has no equivalent to the Ext2/3/4 
fsck program.  /bin/fsck.btrfs is a shell script that returns 8 if the device 
doesn't exist and 0 in all other cases, it has a comment saying "You should 
set fs_passno to 0".

The design of BTRFS is similar to ZFS in that you expect to be able to push 
reset and have the system just work again with kernel code doing the recovery.

It's definitely a kernel bug.  The question is where the bug is and who will 
fix it.

Thanks for the suggestion though.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/




___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

BTRFS losing SE Linux labels on power failure or "reboot -nffd".

[Russell Coker via Selinux]

The command "reboot -nffd" (kernel reboot without flushing kernel buffers or 
writing 
status) when run on a BTRFS system will often result in 
/var/log/audit/audit.log being 
unlabeled.  It also results in some systemd-journald files like 
/var/log/journal/
c195779d29154ed8bcb4e8444c4a1728/system.journal being unlabeled but that is 
rarer.  I 
think that the same problem afflicts both systemd-journald and auditd but it's 
a race 
condition that on my systems (both production and test) is more likely to 
affect auditd.

If this issue just affected "reboot -nffd" then a solution might be to just not 
run that 
command.  However this affects systems after a power outage.

I have reproduced this bug with kernel 4.9.0-6-amd64 (the latest security 
update for 
Debian/Stretch which is the latest supported release of Debian).  I have also 
reported it in 
an identical manner with kernel 4.16.0-1-amd64 (the latest from 
Debian/Unstable).  For 
testing I reproduced this with a 4G filesystem in a VM, but in production it 
has happened 
on BTRFS RAID-1 arrays, both SSD and HDD.

#!/bin/bash 

Firstly the above is the script /usr/local/sbin/testit, I test for auditd 
running because it 
aborts if the context on it's log file is wrong.

root@stretch:~# ls -liZ /var/log/audit/audit.log 

Above is before I do the tests.

while ssh stretch /usr/local/sbin/testit ; do 

Above is the shell code I run to do the tests.  Note that the VM in question 
runs on SSD 
storage which is why it can consistently boot in less than 20 seconds.

Fri  1 Jun 12:26:13 UTC 2018 

Above is the output from the shell code in question.  After the first reboot it 
fails.  The 
probability of failure on my test system is greater than 50%.

root@stretch:~# ls -liZ /var/log/audit/audit.log  

Now the result.  Note that the Inode has not changed.  I could understand a 
newly created 
file missing an xattr, but this is an existing file which shouldn't have had 
it's xattr changed.  
But somehow it gets corrupted.

Could this be the fault of SE Linux code?  I don't think it's likely but this 
is what the BTRFS 
developers will ask so it's best to discuss this here before sending it to them.

Does anyone have any ideas of other tests I should run?  Anyone want me to try 
a 
different kernel?  I can give root on a VM to anyone who wants to poke at it.  
Anything else 
I should add when sending this to the BTRFS developers?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: run_init messes up terminal settings

[Russell Coker via Selinux]

On Monday, 26 June 2017 11:22:31 AM AEST Stephen Smalley wrote:
> I'd be inclined to just drop open_init_pty (for that matter, I'd like
> to deprecate/drop run_init entirely, but I guess it might be needed if
> not using DIRECT_INITRC=y and not using systemd).

Currently for my use (which involves more strict configurations than most 
Debian users have) the only use of run_init is for running newaliases on a 
Postfix system and for any dpkg commands relating to Postfix (which end up 
running newaliases in the postinst).

The alternative to this is to allow sendmail when run from an unconfined_t or 
sysadm_t shell the ability to write to etc_aliases_t.

Given the problems with run_init and the lack of use of it it seems that 
changing the policy to give slightly more access to sendmail would make sense.

Currently we have user_mail_t as the domain for sendmail when run from 
unconfined_t and user_t.  We need to either have separate domains for this or 
rely on constraints to prevent a user_r session from writing to etc_aliases_t.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: [PATCH v2] libsemanage: remove lock files

[Russell Coker via Selinux]

On Wed, 26 Apr 2017 06:06:13 AM Guido Trentalancia wrote:
> > Pidfile locking also never works across network filesystems as pids
> > are local to 
> > a system.  You could have some combination of pid and hostname (as
> > done by 
> > some web browsers) but that gets ugly.
> 
> No, I didn't mean the complicate circumstance of NFS shared amongst
> multiple systems.
> 
> I only meant the simpler (and most common) situation where the NFS is
> mounted for only one system, therefore PIDs are unique and there is no
> need to include the hostname.

flock(2) seems to indicate that locks always worked locally on NFS filesystems 
and thus would always have worked in that case.

Please do some testing and prove that the problem occurs on NFS-root systems.

> > Really pidfiles are so horrible that one of the noteworthy features
> > of systemd 
> > is removing the need for them.
> 
> I am not that pessimistic about locking with aid of PIDs.
> 
> To be honest, the current situation has more drawbacks in my opinion.
> 
> In particular, I don't like the fact that it leaves unused lock files
> around the filesystem.

Everything else that uses lock files does that.

> > Having multiple systems operate with NFS root and a shared
> > /etc/selinux is 
> > never going to work well.  Even if everything works well (and it
> > probably 
> > won't) you will end up with systems that have the policy in
> > /etc/selinux not 
> > matching what is running.
> 
> Please forget sharing NFS. I meant dedicated NFS.
> 
> Anyway, I have created a new version of the patch that should probably
> improve the previous race condition.
> 
> If you have a way of testing a dedicated store over NFS, then I'd like
> to hear back from you the result of such testing !
> 
> But, if you are not interested in testing it, then never mind...

I think that when someone wants to change behavior that is the same as used in 
many programs they should demonstrate that it has a problem.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: Running Java and JVM on SELinux

[Russell Coker]

On Tue, 4 Apr 2017 02:34:14 PM Rahmadi Trimananda wrote:
> Umm, how's the easiest way to permit that one? Do I need to create a local
> policy or can I just use a command line? Sorry I am really a newbie. :)

Run "audit2allow -l -R < /var/log/audit/audit.log > local.te", that will 
generate the policy.

policy_module(local,0.0.0)

Edit local.te to remove allow lines that you don't want and also add the above 
as the first line.

Create a symlink from the example Makefile (which is /usr/share/doc/selinux-
policy-dev/examples/Makefile on Debian if you have the selinux-policy-dev 
package installed) to the current directory.  Then run "make load" and your 
policy will be compiled and loaded.

> I am using javac 1.8.0_65. It is the same version for the "java" program.
> 
> java version "1.8.0_65"
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)

I'm using openjdk which doesn't appear to require such access.

$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-4-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

> On Mon, Apr 3, 2017 at 7:52 PM, Russell Coker <russ...@coker.com.au> wrote:
> > On Tue, 4 Apr 2017 12:35:47 PM Rahmadi Trimananda wrote:
> > > I have more error messages from /var/log/audit/audit.log if this is of
> > 
> > any
> > 
> > > use for you. And yeah, it works in permissive mode (sudo setenforce 0).
> > > BTW, what do you mean by "run javac in strace"?
> > > 
> > > iotuser@raspberrypi:~/policy $ sudo cat /var/log/audit/audit.log | grep
> > > javac
> > > type=AVC msg=audit(1491260813.624:793): avc:  denied  { mmap_zero } for
> > > 
> > >  pid=1656 comm="javac"
> > > 
> > > scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > tclass=memprotect permissive=0
> > 
> > Try permitting that one and see if it changes things.  What version of
> > javac
> > are you using?  Is it an old version?
> > 
> > Also when posting such things to the list please include the output of
> > auditallow as well as the raw AVC messages whenever you send more than
> > 2-3 entries.  When your MUA wraps the lines the result isn't accepted by
> > audit2allow and that makes it less convenient for us to process your
> > messages
> > (usually audit2allow output is more useful than reading raw AVC log
> > entries).
> > 
> > If there is only a single AVC message then we can all run audit2allow in
> > our
> > heads.  ;)
> > 
> > --
> > My Main Blog http://etbe.coker.com.au/
> > My Documents Bloghttp://doc.coker.com.au/

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: ssh/cron access checks and my Play Machine

[Russell Coker]

On Sun, 2 Apr 2017 01:25:41 AM Dominick Grift wrote:
> So youre saying the a policy upgrade changed the permissions of
> ~/.ssh/authorized_keys from 0600 to  how is that possible? Also is ~

No, a policy upgrade and relabel.

> not set to 0700? User wouldnt be able to traverse to other uids' ~/.ssh

Unless they have the same UID, which is the point of a Play Machine.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

ssh/cron access checks and my Play Machine

[Russell Coker]

Ever since the earliest days of SE Linux (at least 2001 according to my 
recollection) the cron patches for SE Linux have included a check of the 
context of the crontab file to ensure that the policy specifies that it is 
permitted to have crontab entries to run in the context in question.  Such 
checks were comparable to the checks in crond for a UID match for running the 
job with Unix permissions, but a little more complex because we aren't just 
dealing with UIDs.

The sshd checks the Unix permissions of ~/.ssh/authorized_keys to ensure that 
only the owner of the account in question and the primary group of that 
account can write to it, ~/.ssh, and ~.  But we don't have similar checks for 
SE Linux permissions.  I really should have thought of this back when I was 
doing a lot of the maintenance for the SE Linux patches for cron and sshd.

To test this, try "chmod 666 ~/.ssh/authorized_keys" and then observe that you 
can't ssh to that account without a password.  Then use chcon to set the type 
of the authorized_keys file to something inappropriate but readable by sshd_t 
(such as user_tmpfs_t or etc_t) or set the identity to something other than 
system_u or the identity of the account in question and observe that you can 
still login without a password.

During a recent upgrade to my SE Linux Play Machine (or to be more specific the 
Debian/Unstable Play Machine that recently replaced the Debian/Jessie 
instance) the permissions were reset on the home directory of the sysadm_r 
account by a policy upgrade and I didn't notice and set them correctly.  This 
made it theoretically possible for a user_r user to modify the authorized_keys 
file, login to the sysadm_r account, and then totally pwn the system.

Today I noticed that sshd was taking more memory than usual and user_r logins 
were failing with the error "fatal: monitor_apply_keystate: packet_set_state: 
memory allocation failed".  Only user_r logins were failing because only 
user_r has a memory limit set in /etc/security/limits.conf.  This raises the 
possibility that someone replaced sshd or a library it depends on.  I'll make 
the system image available to anyone who wants to do forensics.  I am not 
certain that the system was compromised at this stage.  But given that it 
could have been compromised and that it was operating in a different way to 
what I expected I think it's most reasonable to assume that it was.

Some people may wonder why I am posting this on the first of April.  Someone 
sent an April 1st joke to a mailing list that had obfuscinated shell code and 
my usual practice is to login to my Play Machine as user_r to run suspect 
code.  This is what led me to discover the problem.  That said, there is 
evidence that the system might have been running correctly yesterday.

When running such systems there have been a number of incidents of problems 
discovered.  As long as the end result is improvement of knowledge about 
computer security (both by the person running the system and the community) or 
an improvement in SE Linux to make such attacks more difficult in future (which 
I aim to implement by changes to policy and PAM/sshd code) it can be counted 
as a win for us.  I think that this will end up achieving the aims of 
education and software improvement.  So while it sucks a bit, the end result 
should be positive.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: label for /proc directory (before mounting)

[Russell Coker]

On Thu, 30 Mar 2017 08:00:42 AM Colin Walters wrote:
> This causes some breakage in rpm-ostree (which I can work
> around), but I'd like a better fix than what I did above.
> Any suggestions?  It probably doesn't
> matter too much what the actual type is since systemd will
> overmount it - should I make it the same type as e.g. `/mnt`?

I've been thinking of submitting a patch for /proc and other mountpoints to be 
mnt_t or root_t for some time.  Your suggestion sounds good to me.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: net_admin audit for setsockopt SO_SNDBUFFORCE

[Russell Coker]

On Wednesday, 22 March 2017 9:28:13 AM AEDT Stephen Smalley wrote:
> > > Probably not, since SO_SNDBUFFORCE only exists to allow a process
> > > with
> > > CAP_NET_ADMIN to override the wmem_max limit per the man
> > > page.  IOW,
> > > only processes with CAP_NET_ADMIN should ever use that option. 
> > > dontaudit'ing that does not seem like a good idea either; I think
> > > you
> > > have to allow it or risk silent breakage.
> > 
> > We have had sshd, tor, and rpcbind denied access to that for some
> > time without 
> > any apparent breakage.
> 
> Two concerns with that:
> 1) The breakage might be subtle and not apparent, but nonetheless real.
>   They are presumably using SO_SNDBUFFORCE for a reason, not just for
> fun.  At the least, it may be degrading performance, possibly
> increasing potential for DoS, or similar.

For TOR the issue of DoS is relevant, although I am dubious about the idea 
that TOR might be unable to operate with the default buffer settings of any 
supported OS.  Also I'm generally dubious about the idea that a DoS might be 
enabled by preventing a daemon from enlarging it's buffers rather than being 
prevented by it.

Generally rpcbind should not be exposed to the public Internet, if it is then 
you might have bigger problems than buffer sizes.

As sshd is one of the most common targets of attack on the Internet it seems 
very unlikely to me that buffer sizes would be the problem.  For most servers 
it's just non-stop probes and attempts to brute-force passwords on port 22.

> 2) If we dontaudit net_admin now for SO_SNDBUFFORCE, and any of these
> programs later introduce code (or any of the libraries that they use do
> so) that actually requires net_admin for another purpose, we won't see
> the denial and users will experience breakage with no indication as to
> cause.

Yes this is a real issue.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: net_admin audit for setsockopt SO_SNDBUFFORCE

[Russell Coker]

On Tuesday, 21 March 2017 2:01:04 PM AEDT Stephen Smalley wrote:
> On Tue, 2017-03-21 at 16:06 +0100, cgzones wrote:
> > Hi list,
> > this thread[1] about setsockopt(...,...,SO_SNDBUFFORCE), which
> > triggers widely due to systemd, let me think about the recent SELinux
> > kernel fixes: the reordering of dac_read_search and dac_override and
> > also the cap_wake_alarm fix.
> > 
> > Would it make sense to test, if the send buffer is really set to a
> > higher value than wmem_max, before testing for the cap_net_admin
> > permission[2]?
> > (might also apply to SO_RCVBUFFORCE)
> 
> Probably not, since SO_SNDBUFFORCE only exists to allow a process with
> CAP_NET_ADMIN to override the wmem_max limit per the man page.  IOW,
> only processes with CAP_NET_ADMIN should ever use that option. 
> dontaudit'ing that does not seem like a good idea either; I think you
> have to allow it or risk silent breakage.

We have had sshd, tor, and rpcbind denied access to that for some time without 
any apparent breakage.

> What would perhaps be better would be to introduce LSM hooks to allow
> finer-grained distinctions to be made among the different CAP_NET_ADMIN
> cases, ala issue #26.  Then the impact of allowing net_admin would be
> less significant.

Yes that would be good.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Custom Process Label (SElinux)

[Russell Coker]

On Thu, 9 Mar 2017 08:42:26 PM Kashif ali wrote:
>   i have created a module for my custom service with seplogen command it
> has generated the policy module for my custom service and context for its
> /usr/bin/mycustomeservicedaemon which is custom_service_exec_t when i run
> my service it doesn't get the label of  custom_service_t where as it has
> the label of init_t so thats mean that the proper domain transition is not
> available or there is something which is i'm missing.

Did you run "restorecon -v /usr/bin/mycustomeservicedaemon"?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Securing a service written in Python

[Russell Coker]

On Thu, 2 Mar 2017 11:03:15 AM Ian Pilcher wrote:
> Can anyone provide any pointers, links, advice, examples, etc. for
> writing a policy to secure a service written in Python?

Why would it be any different to services written in Perl and other interpreted 
languages?

Mailman is written in Python and works well for me on SE Linux systems.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: SELinux type transition rule not working

[Russell Coker]

On Thu, 2 Mar 2017 08:40:49 AM Ian Pilcher wrote:
> I am using systemd's RuntimeDirectory to create a directory for a
> service.
> 
> RuntimeDirectory=squoxy
> 
> This causes systemd to create /run/squoxy before starting my service,
> but I haven't been able to get the SELinux context set correctly on the
> directory.
> 
> I've set file context rules for both /run/squoxy and /var/run/squoxy:
> 
> ^/var/run/squoxy(/.*)?  all files  system_u:object_r:squoxy_var_run_t:s0
> ^/run/squoxy(/.*)?  all files  system_u:object_r:squoxy_var_run_t:s0
> 
> And, indeed, restorecon will set the context of the directory to
> squoxy_var_run_t.

If restorecon gives the correct context and systemd-tmpfiles does too 
(according to one of your later messages) then this is a bug in systemd.

It's probably best to raise it in the systemd bug tracker.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

strange audit2allow error

[Russell Coker]

# audit2allow -l < /var/log/audit/audit.log -R

require {
type devicekit_power_t;
}

#= devicekit_power_t ==
devicekit_dbus_chat_power(devicekit_power_t)
# audit2allow -l < /var/log/audit/audit.log 


#= devicekit_power_t ==
allow devicekit_power_t dpkg_script_t:dbus send_msg;

Above is the output of audit2allow.  For some reason audit2allow -R is 
generating the wrong parameter for devicekit_dbus_chat_power().

Here is the interface in question:


## 
##  Send and receive messages from
##  devicekit power over dbus.
## 
## 
##  
##  Domain allowed access.
##  
## 
#
interface(`devicekit_dbus_chat_power',`
gen_require(`
type devicekit_power_t;
class dbus send_msg;
')

allow $1 devicekit_power_t:dbus send_msg;
allow devicekit_power_t $1:dbus send_msg;
')

Any ideas on how to debug this?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: strange avc

[Russell Coker]

Thanks for the information. That's the Debian/Jessie kernel and it's years too 
late to get it fixed. Oh well at least it fails closed.

On 26 January 2017 12:22:35 am LHDT, Stephen Smalley 
<stephen.smal...@gmail.com> wrote:
>On Wed, Jan 25, 2017 at 1:22 AM, Russell Coker <russ...@coker.com.au>
>wrote:
>> type=AVC msg=audit(1485258907.829:106): avc:  denied  { 0x80 }
>for
>> pid=1280 comm="rewrite-0" name="after-the-deadline" dev="vda"
>ino=104107534
>> scontext=system_u:system_r:httpd_t:s0
>> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
>>
>> I got the above after upgrading a system running kernel 3.16.0 to the
>latest
>> userspace.  Why is this happening?  Is this a bug?
>
>That would be a kernel bug; it means that you have a directory inode
>(for which that permission would be rmdir permission) that is wrongly
>assigned the file security class.  Typically means that the filesystem
>did not set the file mode format bits before security_d_instantiate()
>was called.
>___
>Selinux mailing list
>Selinux@tycho.nsa.gov
>To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>To get help, send an email containing "help" to
>selinux-requ...@tycho.nsa.gov.

-- 
Sent from my Nexus 6P with K-9 Mail.

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Another getcon() vs getcon_raw() issue in systemd

[Russell Coker]

On Monday, 26 December 2016 7:10:19 PM AEDT Nicolas Iooss wrote:
> With the output you gave I searched in D-Bus source how the
> LinuxSecurityLabel was computed here. I discovered a lot of files in dbus/
> directory which seem to duplicate things from bus/ I have described in my
> previous email. In dbus/dbus-sysdeps-unix.c there is a function which calls
> "getsockopt (client_fd, SOL_SOCKET, SO_PEERSEC, ...)" in order to get this
> "system_u:system_r:systemd_machined_t:s0"
> (add_linux_security_label_to_credentials,
> https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c?h=dbus-> 
> 1.10#n1760). This function queries the same kernel API as libselinux's
> getpeercon_raw(), but without using libselinux (which is normal as it can
> also returns Smack or AppArmor labels). This is why the context is not
> translated.
> 
> The documentation of GetConnectionCredentials->LinuxSecurityLabel is way
> better than the one of GetConnectionSELinuxSecurityContext in D-Bus
> specification (
> https://cgit.freedesktop.org/dbus/dbus/tree/doc/dbus-specification.xml?h=dbu
> s-1.10#n6030) so if I were to decide, I would rather migrate systemd's
> bus_get_name_creds_dbus1() to GetConnectionCredentials (in
> https://github.com/systemd/systemd/blob/v232/src/libsystemd/sd-bus/bus-contr
> ol.c#L865). However this implies some non-trivial systemd code modifications
> and I do not know how systemd developers are willing to modify this part of
> their code.
> An other option consists in making D-Bus use getpeercon_raw() in
> GetConnectionSELinuxSecurityContext (and documenting this in the D-Bus
> spec). I do not know what subtle side-effects such a change would have on a
> system (a quick search of users of this interface on searchcode.com gave
> some Android-related projects).

Thanks for your suggestions.  I ran a VM of Fedora 24 with my policy to test 
this.  Fedora 24 ran well with that and gave no such errors.  Fedora has dbus 
1.11.8 (development) and systemd 229 while Debian/Unstable has dbus 1.10.14 
(stable) and systemd 332.

A did a diff on the Fedora 24 dbus source and the Debian dbus source and 
didn't find anything that seemed to be related.  So I presume that it's more 
related to systemd - which doesn't necessarily imply that changing systemd is 
the correct way to fix it.

I'll try rawhide now.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Policy disable error

[Russell Coker]

That sort of thing is a bug and should be fixed. If it can't be fixed then IMHO 
the Apache module should be linked in base.pp to make it explicit that it 
shouldn't be removed.

On 15 September 2015 10:08:21 pm AEST, Dominick Grift  
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>On Tue, Sep 15, 2015 at 05:25:58PM +0530, Divya Vyas wrote:
>> Hi,
>> 
>> I am getting below error while disabling the apache module policy
>> 
>> semodule -d apache
>> libsepol.context_from_record: type httpd_sys_content_t is not defined
>(No
>> such file or directory).
>> libsepol.context_from_record: could not create context structure
>(Invalid
>> argument).
>> libsemanage.validate_handler: invalid context
>> system_u:object_r:httpd_sys_content_t:s0 specified for htdocs/ [all
>files]
>> (Invalid argument).
>> libsemanage.dbase_llist_iterate: could not iterate over records
>(Invalid
>> argument).
>> semodule:  Failed!
>
>most likely a dependency issue. apache module is notorious for being
>essentially mandatory.
>
>You would have to identity all modules that depends on the apache
>module
>and then disable those as well in the same transaction. Be warned that
>those modules in turn may have dependencies of their own.
>
>kind of like "dll hell" in a sense
>
>- -- 
>02DFF788
>4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
>https://sks-keyservers.net/pks/lookup?op=get=0x314883A202DFF788
>Dominick Grift
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQGcBAEBCgAGBQJV+AovAAoJENAR6kfG5xmcx4wL/jZrT5OvwN3xpWd+/fHl/unO
>fqowsf+h+IPHIJblVpsd9byMRqmVtka5I630/g9UMpdj/oGyeLFqiNSvwveVAdJV
>LymzJ7+OT8R8oSakSK5xI3cf2l6yx1q+vDNueJaoP8Ss9XSmNf/tefSOc66QKtNy
>1KIXSqaQLZwhT85QjtKjBD8KmQkxIMO4nMNBiBkQCbbqBlHfYYZummSdHfQt8xz7
>2e05ycc2lUrJLlztQUWXrHkFRqM7g5I6SKOoCJfed1uxWb3gVNPVJIDpJeDdDNmF
>UpDvmlq72JTUvv1qjJskiIIU4NMfV469B/3OyMIrdORkEzPgiNNnUdyTro8Pwnk2
>C2g8Ef57CCQC78tPeAMP57IJKMhq32fc+TBgNAyNfQqNvFMmGEdqTWFmImpv6ula
>yW1oSJa+6NBhvkB44LVqwh2GY0ei1dfQV1sOOLc6QARmMQm3glSrk500z/3s55eo
>opuPIJN4XGy1ODI8Yy9i+7dsFTxUFl8qqM37rfoNpQ==
>=sDw/
>-END PGP SIGNATURE-
>___
>Selinux mailing list
>Selinux@tycho.nsa.gov
>To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>To get help, send an email containing "help" to
>selinux-requ...@tycho.nsa.gov.

-- 
Sent from my Nexus 6P with K-9 Mail.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Diskless system running SELinux

[Russell Coker]

Sorry for the late reply, but have you considered iSCSI, NBD, and other similar 
things?

On 8 January 2016 8:48:21 am AEDT, Andrew Ruch  wrote:
>Hello,
>
>I'm researching deploying a diskless system that would use PXEBoot and
>NFS for it's storage. I believe this capability has been proven and
>have no issues here. The tricky part is this system must also have
>Mandatory Access Control. I thought RHEL 7.2 was the answer due to
>it's support of labeled NFS. However, Red Hat just told me that having
>an SELinux-labeled, remote root partition is unsupported. What wasn't
>clear was if the problem was in RHEL or something upstream.
>
>Does the kernel support a labeled, remote root partition? If so, which
>distributions support this?
>
>
>Thanks,
>Andrew Ruch
>___
>Selinux mailing list
>Selinux@tycho.nsa.gov
>To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>To get help, send an email containing "help" to
>selinux-requ...@tycho.nsa.gov.

-- 
Sent from my Nexus 6P with K-9 Mail.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: ANN: Reference Policy Release

[Russell Coker]

On Sunday, 23 October 2016 5:29:25 PM AEDT Chris PeBenito wrote:
> A new release of the SELinux Reference Policy is now available on the
> GitHub site, https://github.com/TresysTechnology/refpolicy.

https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease

The archive at the above page has the files policy.28 and policy.30.orig which 
comprise more than half the compressed archive size.

Could you make a new release without them?  Otherwise we are going to have 
that in all the distribution archives and mirror sites.

Also in future could we have more frequent releases?  More frequent upstream 
releases makes it easier for distribution people to send changes upstream and 
gives a greater incentive to do so.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Planet SE Linux

[Russell Coker]

On Mon, 1 Aug 2016 01:02:14 AM Jason Zaman wrote:
> I've been meaning to start a blog but never quite gotten around to it.
> so +1 if you want to run it! Planet makes more sense to me too than just a
> list.

It's easy to run a blog.  I recommend going for a self-hosted Wordpress 
installation right from the start.  If you start using LiveJournal or 
something then you will have some hassle when it comes time to move to your 
own domain.

The general idea of Planet SE Linux was that it had almost excluseively posts 
related to computer security.  I have a "security" category on my blog that I 
started just for Planet SE Linux.  It covers lots of things that aren't 
related to SE Linux, but I expect that most people who are interested in SE 
Linux don't mind reading about DNSSEC etc.  But I know that some people here 
don't want to read some of my other blog posts.  ;)  If you aren't planning to 
just blog about SE Linux you might want to do something similar.  Contact me 
off-list if you want advice on setting up a blog with separate feeds.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Planet SE Linux

[Russell Coker]

On Sun, 31 Jul 2016 11:13:57 PM Paul Moore wrote:
> > Is there interest in having a working Planet SE Linux again?  I'm happy
> > to run it either on my own site or somewhere else if there's interest.
> 
> I tend to prefer just loading the individuals blogs into my own feed
> reader instead of going through a planet aggregator.  However, I do
> find planet aggregator sometimes helpful to discover new, related
> blogs.  Perhaps simply a maintained list of SELinux related blogs
> would be helpful.

There are probably more than a few people who have that plan.  However running 
a Planet installation is no more work than maintaining a list of blogs.  In 
fact there's a benefit to a Planet installation in that it will tell you when a 
blog has been inactive for a long time and show you when a blog has been taken 
over by a porn site (as recently happened to someone many of us know).  In 
terms of people who want a list of blogs the advantage of a Planet 
installation is that they can page-down to quickly see which blogs have 
content that interests them.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Planet SE Linux

[Russell Coker]

http://selinuxnews.org/planet/

Planet SE Linux has gone away.

Is there interest in having a working Planet SE Linux again?  I'm happy to run 
it either on my own site or somewhere else if there's interest.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH] libselinux: If autorelabel, force permissive mode.

[Russell Coker]

On Fri, 8 Jul 2016 06:56:14 AM Richard W.M. Jones wrote:
> On Thu, Jul 07, 2016 at 09:50:17PM +0800, Jason Zaman wrote:
> > Doesn't Android set the labels on the /system disk image during build?
> > Maybe virt-builder can copy that? This would also speed up initial
> > deployment of new images.
> 
> Well this is the real problem.  Because the guest policy is a binary
> blob, and because the binary blobs are not (necessarily) compatible
> across kernel versions, we cannot just load the policy blob of the
> guest into our kernel, so we cannot label guests properly.  Sure be
> nice if policy wasn't stored in this way.

While virt-builder is one case that needs special attention the important fact 
is that autorelabel has never worked as well as it should have.  There has 
never been a guarantee that an autorelabel operation would complete 
successfully in the face of the wrong combination of mislabeled files.  It 
might be a good idea to copy the Android build process to virt-builder for 
other reasons but even so the design Richard proposes is worth having 
regardless.

Also the way that the reboot was managed was never that great, especially on a 
systemd system.  I can't recall how much of that is my responsibility.

I'd like to get this in Debian.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: selinux_set_callback() problem

[Russell Coker]

On Sat, 6 Feb 2016 05:29:05 AM Stephen Smalley wrote:
> On 02/04/2016 04:32 PM, Russell Coker wrote:
> > type=USER_AVC msg=audit(1454447396.743:48359): pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > msg='avc:  denied  { status } for auid=0 uid=0 gid=0
> > path="/lib/systemd/system/reboot.target"
> > cmdline="reboot"
> > scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:systemd_unit_file_t:SystemLow tclass=service
> > exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > 
> > I'm seeing entries like the above from the Debian/Jessie systemd in
> > audit.log. Below is the relevant code from the systemd source:
> > 
> > _printf_(2, 3) static int log_callback(int type, const char *fmt, ...) {
> > 
> >  va_list ap;
> > 
> > #ifdef HAVE_AUDIT
> > 
> >  if (get_audit_fd() >= 0) {
> >  
> >  _cleanup_free_ char *buf = NULL;
> >  int r;
> >  
> >  va_start(ap, fmt);
> >  r = vasprintf(, fmt, ap);
> >  va_end(ap);
> >  
> >  if (r >= 0) {
> >  
> >  audit_log_user_avc_message(get_audit_fd(),
> > 
> > AUDIT_USER_AVC, buf,
> > NULL, NULL, NULL, 0);
> > 
> >  return 0;
> >  
> >  }
> >  
> >  }
> > 
> > #endif
> > 
> >  va_start(ap, fmt);
> >  log_metav(LOG_USER | LOG_INFO, __FILE__, __LINE__, __FUNCTION__,
> >  fmt,
> > 
> > ap);
> > 
> >  va_end(ap);
> >  
> >  return 0;
> > 
> > }
> > 
> > Then the following line is in the access_init() function to enable it:
> > 
> > selinux_set_callback(SELINUX_CB_LOG, (union selinux_callback)
> > log_callback);
> > 
> > Any suggestions as to where I should start working on this?
> > 
> > Sorry if it's a newbie question, I haven't worked on SE Linux library
> > code for a while.
> 
> What exactly is the problem?  Is it that the scontext has a raw context
> and the tcontext has a translated context?  Or is it that it was denied
> when it should have been allowed?
> 
> The callback itself is obviously being executed or you wouldn't have the
> audit message at all.

The problem is a translated context which breaks audit2allow.  Even if it 
didn't break audit2allow it wouldn't be a good thing to have as the text 
representations can (in theory at least) change.

# audit2allow -l < /var/log/audit/audit.log
libsepol.mls_from_string: invalid MLS context SystemLow
libsepol.mls_from_string: could not construct mls context structure
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert 
system_u:object_r:systemd_unit_file_t:SystemLow to sid


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

selinux_set_callback() problem

[Russell Coker]

type=USER_AVC msg=audit(1454447396.743:48359): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/lib/systemd/system/reboot.target" 
cmdline="reboot" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:systemd_unit_file_t:SystemLow tclass=service  
exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

I'm seeing entries like the above from the Debian/Jessie systemd in audit.log.  
Below is the relevant code from the systemd source:

_printf_(2, 3) static int log_callback(int type, const char *fmt, ...) {
va_list ap;

#ifdef HAVE_AUDIT
if (get_audit_fd() >= 0) {
_cleanup_free_ char *buf = NULL;
int r;

va_start(ap, fmt);
r = vasprintf(, fmt, ap);
va_end(ap);

if (r >= 0) {
audit_log_user_avc_message(get_audit_fd(), 
AUDIT_USER_AVC, buf, 
NULL, NULL, NULL, 0);
return 0;
}
}
#endif

va_start(ap, fmt);
log_metav(LOG_USER | LOG_INFO, __FILE__, __LINE__, __FUNCTION__, fmt, 
ap);
va_end(ap);

return 0;
}

Then the following line is in the access_init() function to enable it:

selinux_set_callback(SELINUX_CB_LOG, (union selinux_callback) log_callback);

Any suggestions as to where I should start working on this?

Sorry if it's a newbie question, I haven't worked on SE Linux library code for 
a while.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.