[PATCH] MAINTAINERS: update the LSM and SELinux subsystems
From: Paul Moore The SELinux code, security/selinux/, already has a MAINTAINERS entry so exclude it from the security subsystem entry in an effort to better reflect current practices. Signed-off-by: Paul Moore --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff51b5f..67e4c4f92ba9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12769,6 +12769,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git W: http://kernsec.org/ S: Supported F: security/ +X: security/selinux/ SELINUX SECURITY MODULE M: Paul Moore ___ 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/next rebased to v4.18-rc1
A quick note to let you know that I've rebased selinux/next on top of v4.18-rc1, and now that merge window is closed I'm going to be working my way through the patch backlog this week. You may also notice that there is now a README.md in the selinux/master branch with some basic information and links. Eventually I'm going to add administrative information, e.g. the SELinux kernel process[1], to this file so we have it in a central location, but if there is anything else you can think of that should be in this file let me know. [1] http://www.paul-moore.com/blog/d/2017/07/kernel_repo_process.html -- paul moore www.paul-moore.com ___ 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: 'setsebool -P' works but throws errors; changes not permanent
> -Original Message- > From: Stephen Smalley > Sent: Monday, June 18, 2018 15:28 > To: Mike Hughes ; selinux@tycho.nsa.gov > Subject: Re: 'setsebool -P' works but throws errors; changes not permanent > > On 06/18/2018 03:44 PM, Mike Hughes wrote: > > We use Yubikey for two-factor ssh authentication which requires enabling a > > Boolean > called “authlogin_yubikey”. It has been working fine until a few weeks ago. > Errors appear > when attempting to set the policy: > > > > > > > > -- > > > > [Cent-7:root@my_server home]# getsebool authlogin_yubikey > > > > authlogin_yubikey --> off > > > > > > > > [Cent-7:root@my_server home]# setsebool -P authlogin_yubikey on > > > > libsepol.context_from_record: type gpio_device_t is not defined > > > > 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:gpio_device_t:s0 to > sid > > > > invalid context system_u:object_r:gpio_device_t:s0 > > Sounds like your policy is in an inconsistent internal state (somewhere you > have a context > with gpio_device_t but the type isn't defined in the policy). > > What's your policy version? And did it perhaps fail during %post when it was > updated - > check yum.log? Nothing stands out to me in yum.log > Does semodule -B fail? No, it completes without error: -- [Cent-7:root@my_server ~]# semodule -B [Cent-7:root@ my_server ~]# echo $? 0 [Cent-7:root@ my_server ~]# -- > > Might have to move aside your policy and reinstall it. How might one accomplish this? > > > > [Cent-7:root@my_server home]# getsebool authlogin_yubikey > > > > authlogin_yubikey --> on > > > > --- > > > > > > > > The system accepts two-factor while the above is set to “on”. After some > > undetermined > time (or immediately after a reboot) the Boolean toggles off. This can be > confirmed since > semanage shows that the default is still set to “off”: > > > > > > > > -- > > > > [Cent-7:root@my_server ~]# semanage boolean -l | grep "authlogin_yubikey" > > > > SELinux boolean State Default Description > > > > ... > > > > authlogin_yubikey (on , off) Allow authlogin to yubikey > > > > -- > > > > > > > > It looks similar to the following bug on Fedora: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1559174 ___ 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: 'setsebool -P' works but throws errors; changes not permanent
On 06/18/2018 03:44 PM, Mike Hughes wrote: > We use Yubikey for two-factor ssh authentication which requires enabling a > Boolean called “authlogin_yubikey”. It has been working fine until a few > weeks ago. Errors appear when attempting to set the policy: > > > > -- > > [Cent-7:root@my_server home]# getsebool authlogin_yubikey > > authlogin_yubikey --> off > > > > [Cent-7:root@my_server home]# setsebool -P authlogin_yubikey on > > libsepol.context_from_record: type gpio_device_t is not defined > > 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:gpio_device_t:s0 to sid > > invalid context system_u:object_r:gpio_device_t:s0 Sounds like your policy is in an inconsistent internal state (somewhere you have a context with gpio_device_t but the type isn't defined in the policy). What's your policy version? And did it perhaps fail during %post when it was updated - check yum.log? Does semodule -B fail? Might have to move aside your policy and reinstall it. > > > > [Cent-7:root@my_server home]# getsebool authlogin_yubikey > > authlogin_yubikey --> on > > --- > > > > The system accepts two-factor while the above is set to “on”. After some > undetermined time (or immediately after a reboot) the Boolean toggles off. > This can be confirmed since semanage shows that the default is still set to > “off”: > > > > -- > > [Cent-7:root@my_server ~]# semanage boolean -l | grep "authlogin_yubikey" > > SELinux boolean State Default Description > > ... > > authlogin_yubikey (on , off) Allow authlogin to yubikey > > -- > > > > It looks similar to the following bug on Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=1559174 > > > > ___ > 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 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: is_selinux_enabled() after chroot()
On 06/18/2018 03:24 PM, Petr Lautrbach wrote:
> Hello,
>
> libselinux sets selinut_mnt and has_selinux_config only in its constructor and
> is_selinux_enabled() and others just use selinux_mnt to check if SELinux is
> enabled. But it doesn't work correctly when you use chroot() to a directory
> without /proc
> and /sys/fs/selinux mounted as it was discovered in
> https://bugzilla.redhat.com/show_bug.cgi?id=1321375
>
> In this case, is_selinux_enabled() after chroot() returns true while in a new
> program run from chrooted process it returns false. It can be demonstrated by
> the steps below.
>
> The solution could be to check if selinux_mnt still exists whenever a function
> depending on this is called. Would this be acceptable?
You want to call stat() or access(F_OK) on selinux_mnt and/or SELINUXCONFIG in
is_selinux_enabled()?
Could potentially trigger a permission check that wasn't previously required,
thereby breaking existing policies.
Caller might just be checking to see if SELinux is enabled before using
interfaces other than selinuxfs (e.g. setexeccon, setfilecon, etc) and
therefore didn't previously need permissions to selinuxfs or
/etc/selinux/config.
So, possible but you'd need to make sure you don't break anything. Definitely
don't want that changed in Android.
>
>
>
>
> $ sudo dnf --nogpg --installroot=/var/lib/machines/example install systemd
>
> $ cat > test_libselinux.c < #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[]) {
> pid_t pid;
> int wstatus;
>
> if (argc > 1) {
> printf("SELinux in chrooted process: %d\n", is_selinux_enabled());
> return 0;
> }
> if (chroot("/var/lib/machines/example") != 0)
> return -1;
>
> printf("SELinux in process after chroot(): %d\n", is_selinux_enabled());
> printf("/sys/fs/selinux exists: %d\n", access("/sys/fs/selinux", F_OK));
> printf("/etc/selinux/config exists: %d\n\n", access("/etc/selinux/config",
> F_OK));
>
> if ((pid = fork()) == 0 ) {
> execv("./test_is_selinux_enabled", (char *[]){
> "./test_is_selinux_enabled", "chrooted", NULL});
> }
>
> wait();
> return 0;
> }
> EOF
>
> $ gcc -o test_is_selinux_enabled test_libselinux.c -lselinux
>
> $ sudo ./test_is_selinux_enabled
> SELinux in process after chroot(): 1
> /sys/fs/selinux exists: -1
> /etc/selinux/config exists: -1
>
> SELinux in chrooted process: 0
>
>
>
> ___
> 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 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.
'setsebool -P' works but throws errors; changes not permanent
We use Yubikey for two-factor ssh authentication which requires enabling a Boolean called "authlogin_yubikey". It has been working fine until a few weeks ago. Errors appear when attempting to set the policy: -- [Cent-7:root@my_server home]# getsebool authlogin_yubikey authlogin_yubikey --> off [Cent-7:root@my_server home]# setsebool -P authlogin_yubikey on libsepol.context_from_record: type gpio_device_t is not defined 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:gpio_device_t:s0 to sid invalid context system_u:object_r:gpio_device_t:s0 [Cent-7:root@my_server home]# getsebool authlogin_yubikey authlogin_yubikey --> on --- The system accepts two-factor while the above is set to "on". After some undetermined time (or immediately after a reboot) the Boolean toggles off. This can be confirmed since semanage shows that the default is still set to "off": -- [Cent-7:root@my_server ~]# semanage boolean -l | grep "authlogin_yubikey" SELinux booleanState Default Description ... authlogin_yubikey (on , off) Allow authlogin to yubikey -- It looks similar to the following bug on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1559174 ___ 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.
is_selinux_enabled() after chroot()
Hello,
libselinux sets selinut_mnt and has_selinux_config only in its constructor and
is_selinux_enabled() and others just use selinux_mnt to check if SELinux is
enabled. But it doesn't work correctly when you use chroot() to a directory
without /proc
and /sys/fs/selinux mounted as it was discovered in
https://bugzilla.redhat.com/show_bug.cgi?id=1321375
In this case, is_selinux_enabled() after chroot() returns true while in a new
program run from chrooted process it returns false. It can be demonstrated by
the steps below.
The solution could be to check if selinux_mnt still exists whenever a function
depending on this is called. Would this be acceptable?
$ sudo dnf --nogpg --installroot=/var/lib/machines/example install systemd
$ cat > test_libselinux.c <
#include
#include
#include
#include
int main(int argc, char *argv[]) {
pid_t pid;
int wstatus;
if (argc > 1) {
printf("SELinux in chrooted process: %d\n", is_selinux_enabled());
return 0;
}
if (chroot("/var/lib/machines/example") != 0)
return -1;
printf("SELinux in process after chroot(): %d\n", is_selinux_enabled());
printf("/sys/fs/selinux exists: %d\n", access("/sys/fs/selinux", F_OK));
printf("/etc/selinux/config exists: %d\n\n", access("/etc/selinux/config",
F_OK));
if ((pid = fork()) == 0 ) {
execv("./test_is_selinux_enabled", (char *[]){ "./test_is_selinux_enabled",
"chrooted", NULL});
}
wait();
return 0;
}
EOF
$ gcc -o test_is_selinux_enabled test_libselinux.c -lselinux
$ sudo ./test_is_selinux_enabled
SELinux in process after chroot(): 1
/sys/fs/selinux exists: -1
/etc/selinux/config exists: -1
SELinux in chrooted process: 0
signature.asc
Description: 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.
[PATCH] python/semanage: Stop logging loginRecords changes
semanage_seuser_modify_local and semanage_seuser_del_local already do
the logging.
Moreover, semanage log for loginRecords.__add was flawed since it
reported old-{seuser,role,range} of default user instead of None. This
was caused by selinux.getseuserbyname, which returns values for default
user when the specified username is not found.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1294663
Signed-off-by: Vit Mojzis
---
python/semanage/seobject.py | 8
1 file changed, 8 deletions(-)
diff --git a/python/semanage/seobject.py b/python/semanage/seobject.py
index c76dce85..d3e14a8b 100644
--- a/python/semanage/seobject.py
+++ b/python/semanage/seobject.py
@@ -593,7 +593,6 @@ class loginRecords(semanageRecords):
semanage_seuser_key_free(k)
semanage_seuser_free(u)
-self.mylog.log("login", name, sename=sename, serange=serange,
serole=",".join(serole), oldserole=",".join(oldserole),
oldsename=self.oldsename, oldserange=self.oldserange)
def add(self, name, sename, serange):
try:
@@ -601,7 +600,6 @@ class loginRecords(semanageRecords):
self.__add(name, sename, serange)
self.commit()
except ValueError as error:
-self.mylog.commit(0)
raise error
def __modify(self, name, sename="", serange=""):
@@ -653,7 +651,6 @@ class loginRecords(semanageRecords):
semanage_seuser_key_free(k)
semanage_seuser_free(u)
-self.mylog.log("login", name, sename=self.sename,
serange=self.serange, serole=",".join(serole), oldserole=",".join(oldserole),
oldsename=self.oldsename, oldserange=self.oldserange)
def modify(self, name, sename="", serange=""):
try:
@@ -661,7 +658,6 @@ class loginRecords(semanageRecords):
self.__modify(name, sename, serange)
self.commit()
except ValueError as error:
-self.mylog.commit(0)
raise error
def __delete(self, name):
@@ -694,8 +690,6 @@ class loginRecords(semanageRecords):
rec, self.sename, self.serange = selinux.getseuserbyname("__default__")
range, (rc, serole) = userrec.get(self.sename)
-self.mylog.log_remove("login", name, sename=self.sename,
serange=self.serange, serole=",".join(serole), oldserole=",".join(oldserole),
oldsename=self.oldsename, oldserange=self.oldserange)
-
def delete(self, name):
try:
self.begin()
@@ -703,7 +697,6 @@ class loginRecords(semanageRecords):
self.commit()
except ValueError as error:
-self.mylog.commit(0)
raise error
def deleteall(self):
@@ -717,7 +710,6 @@ class loginRecords(semanageRecords):
self.__delete(semanage_seuser_get_name(u))
self.commit()
except ValueError as error:
-self.mylog.commit(0)
raise error
def get_all_logins(self):
--
2.14.3
___
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.
sepolgen-ifgen fails with current refpolicy
Hello,
With the current refpolicy when running sepolgen-ifgen I get the
following (fatal) error:
/usr/share/selinux/refpolicy/include/support/obj_perm_sets.spt: Syntax error on
line 157 ` [type=TICK]
error parsing headers
error parsing file /usr/share/selinux/refpolicy/include/support/obj_perm_sets.spt: could
not parse text: "/usr/share/selinux/refpolicy/include/support/obj_perm_sets.spt:
Syntax error on line 157 ` [type=TICK]"
The line in question in obj_perm_sets.spt is:
define(`mmap_file_perms',`{ getattr open map read execute ioctl }
refpolicywarn(`mmap_file_perms is deprecated, please use mmap_exec_file_perms
instead')') # deprecated 20171213
sepolgen-ifgen is not happy with the embedded "refpolicywarn" apparently.
Regards,
Laurent Bigonville
___
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.
