hello everyone,
i'm trying to run a postgresql service on my newly-installed centos4 box. i have been able to recreate my users, set up the permissions, and restore the database dump. also, i can already log-in to my databases.
there is, however, one annoying problem. whenever i type \du (or \d or \l) on the psql prompt, i get the following error:
ERROR: relation "pg_catalog.pg_user" does not exist
after some googling, i'm beginning to suspect that this is a SELinux issue. i then try to disable SELinux on the postgresql daemon by doing:
# setsebool postgresql_disable_trans true
that does not work unfortunately as i'm still stuck with the same error.
while i can definitely just disable SELinux on this box, i would want a more elegant solution that solves this annoying problem. can anyone help me on this?
thanks in advance! matt
Just turn off SELinux, it really is a complete pain.
I've managed to set up Linux and Unix boxes securely for years without all the SE Linux baggage.....
All it does is slow the machine down, and adds "bloat" to the OS...
P.
Matt Arnilo S. Baluyos (Mailing Lists) wrote:
hello everyone,
i'm trying to run a postgresql service on my newly-installed centos4 box. i have been able to recreate my users, set up the permissions, and restore the database dump. also, i can already log-in to my databases.
there is, however, one annoying problem. whenever i type \du (or \d or \l) on the psql prompt, i get the following error:
ERROR: relation "pg_catalog.pg_user" does not exist
after some googling, i'm beginning to suspect that this is a SELinux issue. i then try to disable SELinux on the postgresql daemon by doing:
# setsebool postgresql_disable_trans true
that does not work unfortunately as i'm still stuck with the same error.
while i can definitely just disable SELinux on this box, i would want a more elegant solution that solves this annoying problem. can anyone help me on this?
thanks in advance! matt
On Tue, 2005-05-24 at 08:24 +0100, Peter Farrow wrote:
Just turn off SELinux, it really is a complete pain. I've managed to set up Linux and Unix boxes securely for years without all the SE Linux baggage..... All it does is slow the machine down, and adds "bloat" to the OS...
Unfortunately, Mandatory Access Controls (MACs) are a necessary accountability detail needed in many environments.
It's really the only place NT was better than legacy UNIX.
Of course, I would return argue that Linux at least addresses all aspects of the 7 domains of the SSCP _except_ the MAC portion of DAC/MAC, whereas Microsoft only addresses 3 of them in the OS as standard.
But we needed MAC. It's a good thing to have in many environments -- especially where accountability is essential.
Maybe so... and if it works for you then use it, but sometimes when people say "but we needed this or we needed that", they haven't allways sat down and thought "why do we need it" or "do we really 'need' this ?"
Even having worked on government classified networks I have *never* seen an instance where the standard access controls offered by Linux/Unix didn't do what was required.
Often DAC/MAC setups leads to inferior security because they can get very complex to setup, and the term "can't see the wood for the trees" springs to mind.
As is most often the case the best security is the simplest, and DAC/MAC bloat doesn't help in any way.
If some document or requirement or spec says you need it, I would often question the theory behind the spec, and only if a demonstrable need arises (have yet to see that in 20+ years of consulting) then I would do it...
Of course I've also been in this game too long as well to "never say never" and there is always a first time.... :-)
P.
Bryan J. Smith wrote:
On Tue, 2005-05-24 at 08:24 +0100, Peter Farrow wrote:
Just turn off SELinux, it really is a complete pain. I've managed to set up Linux and Unix boxes securely for years without all the SE Linux baggage..... All it does is slow the machine down, and adds "bloat" to the OS...
Unfortunately, Mandatory Access Controls (MACs) are a necessary accountability detail needed in many environments.
It's really the only place NT was better than legacy UNIX.
Of course, I would return argue that Linux at least addresses all aspects of the 7 domains of the SSCP _except_ the MAC portion of DAC/MAC, whereas Microsoft only addresses 3 of them in the OS as standard.
But we needed MAC. It's a good thing to have in many environments -- especially where accountability is essential.
I would agree with Peter on SEL and I have it disabled even though of course the userland tools are still SEL-modified and we have to use libselinux everywhere.
{rant}
One thing that is incredibly annoying with the packaging of *all* Linuxes that I have seen is the sloppy access controls even in the so-called paranoid settings, which only apply to the firewall aspects really. Maybe there are exceptions but even the installation scripts leave files 644 or similar when they only need to be 600. If a file is in user and group for root, then apart from the few other system users that are also members of the root group, 600 is perfectly adequate or 611 if it's a directory and 'go' want to access files within the directory. I wish the package providers would realise this.
At the user level, RH (? was it them?) started off the fashion of giving every user their own group. So groups become immediately pointless. Debian put all users in the same group users - almost as silly. Groups enable a very powerful control mechanism and ignoring them removes at least one dimension from the security.
I know next to nothing about NT controls so I can't comment on whether Linux 'meets' some arbitrary requirements but by (a) limiting access to system files to root (ie the user) and those few other users and (b) fluent use of groups it is possible to use the DAC to close down almost everything.
And to finish the job, use grsecurity which is fairly easy to configure - it appears to be much easier than SEL in particular - and doesn't need any userland tools as it is entirely in the kernel.
{\rant}
Sorry about that!
John
John Logsdon "Try to make things as simple Quantex Research Ltd, Manchester UK as possible but not simpler" j.logsdon@quantex-research.com a.einstein@relativity.org +44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
On Tue, 24 May 2005, Peter Farrow wrote:
Maybe so... and if it works for you then use it, but sometimes when people say "but we needed this or we needed that", they haven't allways sat down and thought "why do we need it" or "do we really 'need' this ?"
Even having worked on government classified networks I have *never* seen an instance where the standard access controls offered by Linux/Unix didn't do what was required.
Often DAC/MAC setups leads to inferior security because they can get very complex to setup, and the term "can't see the wood for the trees" springs to mind.
As is most often the case the best security is the simplest, and DAC/MAC bloat doesn't help in any way.
If some document or requirement or spec says you need it, I would often question the theory behind the spec, and only if a demonstrable need arises (have yet to see that in 20+ years of consulting) then I would do it...
Of course I've also been in this game too long as well to "never say never" and there is always a first time.... :-)
P.
Bryan J. Smith wrote:
On Tue, 2005-05-24 at 08:24 +0100, Peter Farrow wrote:
Just turn off SELinux, it really is a complete pain. I've managed to set up Linux and Unix boxes securely for years without all the SE Linux baggage..... All it does is slow the machine down, and adds "bloat" to the OS...
Unfortunately, Mandatory Access Controls (MACs) are a necessary accountability detail needed in many environments.
It's really the only place NT was better than legacy UNIX.
Of course, I would return argue that Linux at least addresses all aspects of the 7 domains of the SSCP _except_ the MAC portion of DAC/MAC, whereas Microsoft only addresses 3 of them in the OS as standard.
But we needed MAC. It's a good thing to have in many environments -- especially where accountability is essential.
Thanks for your support on this one John,
Often I have seen frustrated sysadmins who can't get things to work because SELinux is getting the way, just diving in with chmod 777 -R * to try and fix a problem, making hard for the sysadmin is not going to improve security, however glamorous, complex or elegant the solution is. KIS is the order of the day for the best security.
Another thing I have noticed is SELinux forces some system packages to deliver meaningless errors: one such example on one of our webservers was httpd was complaining the directory for a website didn't exist, when clearly it did. What was really happening buried in the logs was good old SELinux was denying httpd access to its own html directories (which is a bonkers thing to do), the error from httpd was therefore competely meaningless, yet another example of SELinux making it tougher for the sysadmin.
Additionally dump/restore the staple diet of Linux backup and DR doesn't back up this extra ACL baggage yet, so its useless to most people.
The best thing to do is add this to /etc/selinux/config
SELINUX=disabled
And then get on with the real jobs....
Note this still doesn't get rid of those damn ACL crap buried in the filesystem so dump still complains, so I pipe the output to grep -v "ACL"
:-)
P.
John Logsdon wrote:
I would agree with Peter on SEL and I have it disabled even though of course the userland tools are still SEL-modified and we have to use libselinux everywhere.
{rant}
One thing that is incredibly annoying with the packaging of *all* Linuxes that I have seen is the sloppy access controls even in the so-called paranoid settings, which only apply to the firewall aspects really. Maybe there are exceptions but even the installation scripts leave files 644 or similar when they only need to be 600. If a file is in user and group for root, then apart from the few other system users that are also members of the root group, 600 is perfectly adequate or 611 if it's a directory and 'go' want to access files within the directory. I wish the package providers would realise this.
At the user level, RH (? was it them?) started off the fashion of giving every user their own group. So groups become immediately pointless. Debian put all users in the same group users - almost as silly. Groups enable a very powerful control mechanism and ignoring them removes at least one dimension from the security.
I know next to nothing about NT controls so I can't comment on whether Linux 'meets' some arbitrary requirements but by (a) limiting access to system files to root (ie the user) and those few other users and (b) fluent use of groups it is possible to use the DAC to close down almost everything.
And to finish the job, use grsecurity which is fairly easy to configure - it appears to be much easier than SEL in particular - and doesn't need any userland tools as it is entirely in the kernel.
{\rant}
Sorry about that!
John
John Logsdon "Try to make things as simple Quantex Research Ltd, Manchester UK as possible but not simpler" j.logsdon@quantex-research.com a.einstein@relativity.org +44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
On Tue, 24 May 2005, Peter Farrow wrote:
Maybe so... and if it works for you then use it, but sometimes when people say "but we needed this or we needed that", they haven't allways sat down and thought "why do we need it" or "do we really 'need' this ?"
Even having worked on government classified networks I have *never* seen an instance where the standard access controls offered by Linux/Unix didn't do what was required.
Often DAC/MAC setups leads to inferior security because they can get very complex to setup, and the term "can't see the wood for the trees" springs to mind.
As is most often the case the best security is the simplest, and DAC/MAC bloat doesn't help in any way.
If some document or requirement or spec says you need it, I would often question the theory behind the spec, and only if a demonstrable need arises (have yet to see that in 20+ years of consulting) then I would do it...
Of course I've also been in this game too long as well to "never say never" and there is always a first time.... :-)
P.
Bryan J. Smith wrote:
On Tue, 2005-05-24 at 08:24 +0100, Peter Farrow wrote:
Just turn off SELinux, it really is a complete pain. I've managed to set up Linux and Unix boxes securely for years without all the SE Linux baggage..... All it does is slow the machine down, and adds "bloat" to the OS...
Unfortunately, Mandatory Access Controls (MACs) are a necessary accountability detail needed in many environments.
It's really the only place NT was better than legacy UNIX.
Of course, I would return argue that Linux at least addresses all aspects of the 7 domains of the SSCP _except_ the MAC portion of DAC/MAC, whereas Microsoft only addresses 3 of them in the OS as standard.
But we needed MAC. It's a good thing to have in many environments -- especially where accountability is essential.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2005-05-24 at 04:49, John Logsdon wrote:
At the user level, RH (? was it them?) started off the fashion of giving every user their own group. So groups become immediately pointless.
How so? The point of groups is that you can be in more than one. How does starting out in a group of your own make them pointless? It does give a unique entry by default that the administrator can customize for each user that wants others to be able to access his files.
Well I agree you can be in as many groups as you like. But what I meant was that making your primary group the same as the user means you have no granularity of control without adding extra groups. It makes 0700 the same as 0770.
I suppose as groups essentially relax security, giving each user his/her own groups should make a tighter ship but in practice what people do is to give world access when they shouldn't. The proper solution is to add a group of course. Few do this I think.
But my real rant was against the sloppy access controls at installation time which means that the regular user can look at all sorts of system things they shouldn't. I don't know of any automatic hardening procedure that can correct this.
Best wishes
John
John Logsdon "Try to make things as simple Quantex Research Ltd, Manchester UK as possible but not simpler" j.logsdon@quantex-research.com a.einstein@relativity.org +44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
On Tue, 24 May 2005, Les Mikesell wrote:
On Tue, 2005-05-24 at 04:49, John Logsdon wrote:
At the user level, RH (? was it them?) started off the fashion of giving every user their own group. So groups become immediately pointless.
How so? The point of groups is that you can be in more than one. How does starting out in a group of your own make them pointless? It does give a unique entry by default that the administrator can customize for each user that wants others to be able to access his files.
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
John Logsdon wrote:
Well I agree you can be in as many groups as you like. But what I meant was that making your primary group the same as the user means you have no granularity of control without adding extra groups. It makes 0700 the same as 0770.
Huh? What are you on about? 0700 is and will always be different from 0770.
Making the primary group the same as the user allows the user to grant/deny access to files for those who are part of his group.
I suppose as groups essentially relax security, giving each user his/her own groups should make a tighter ship but in practice what people do is to give world access when they shouldn't. The proper solution is to add a group of course. Few do this I think.
Excuse me? You are not coherent. What does each user having his own group and the user granting access to others have to do with sloppy access? The group permissions allows the user to specify that others don't get to access files while those users who are part of the user's group do. This MAKES group permissions ever more relevant, not immediately pointless.
But my real rant was against the sloppy access controls at installation time which means that the regular user can look at all sorts of system things they shouldn't. I don't know of any automatic hardening procedure that can correct this.
Example? What should not a user look at assuming they know enough to even look for the file.
This line " It makes 0700 the same as 0770. "
in the context of one group per user makes perfect sense to me......
What John is getting at is that if one user is assigned their own individual group, then the concept of groups for security granularity is negated which essentially removes the middle part of the unix permissions syntax as the group and user are one and the same, so 0700 is 0770, and in this instance your comment "0700 is and will always be different from 0770" does not apply.... you are right in that 0700 is different to 0770 but the security upshot is the same if each user has their own unique group and in that scenario there is no functional difference between 0700 and 0770.
This is the essence of John's statement which I think you may have missed....
Hope this makes it clear...
regards
Pete
Feizhou wrote:
John Logsdon wrote:
Well I agree you can be in as many groups as you like. But what I meant was that making your primary group the same as the user means you have no granularity of control without adding extra groups. It makes 0700 the same as 0770.
Huh? What are you on about? 0700 is and will always be different from 0770.
Making the primary group the same as the user allows the user to grant/deny access to files for those who are part of his group.
I suppose as groups essentially relax security, giving each user his/her own groups should make a tighter ship but in practice what people do is to give world access when they shouldn't. The proper solution is to add a group of course. Few do this I think.
Excuse me? You are not coherent. What does each user having his own group and the user granting access to others have to do with sloppy access? The group permissions allows the user to specify that others don't get to access files while those users who are part of the user's group do. This MAKES group permissions ever more relevant, not immediately pointless.
But my real rant was against the sloppy access controls at installation time which means that the regular user can look at all sorts of system things they shouldn't. I don't know of any automatic hardening procedure that can correct this.
Example? What should not a user look at assuming they know enough to even look for the file. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Peter Farrow wrote:
This line " It makes 0700 the same as 0770. "
in the context of one group per user makes perfect sense to me......
What John is getting at is that if one user is assigned their own individual group, then the concept of groups for security granularity is negated which essentially removes the middle part of the unix permissions syntax as the group and user are one and the same, so 0700 is 0770, and in this instance your comment "0700 is and will always be different from 0770" does not apply.... you are right in that 0700 is different to 0770 but the security upshot is the same if each user has their own unique group and in that scenario there is no functional difference between 0700 and 0770.
This is the essence of John's statement which I think you may have missed....
No, you have missed the point of what each user having their own group brings to the table for 0700 and 0770
This allows usera to give userb but no others (other than root of course) full permissions on files that usera wants to share with userb (0770). How else can usera do this if not via usera's group permissions?
At the same time, usera can limit what userb has access to. userb cannot access files that are user and group owned by usera but where usera does not give any permissions at all to members of group usera (0700)
"This allows usera to give userb but no others (other than root of course) full permissions on files that usera wants to share with userb (0770). How else can usera do this if not via usera's group permissions"
they cant if they are each in non joined groups, which is why 0770 is the same as 0700
P.
Feizhou wrote:
Peter Farrow wrote:
This line " It makes 0700 the same as 0770. "
in the context of one group per user makes perfect sense to me......
What John is getting at is that if one user is assigned their own individual group, then the concept of groups for security granularity is negated which essentially removes the middle part of the unix permissions syntax as the group and user are one and the same, so 0700 is 0770, and in this instance your comment "0700 is and will always be different from 0770" does not apply.... you are right in that 0700 is different to 0770 but the security upshot is the same if each user has their own unique group and in that scenario there is no functional difference between 0700 and 0770.
This is the essence of John's statement which I think you may have missed....
No, you have missed the point of what each user having their own group brings to the table for 0700 and 0770
This allows usera to give userb but no others (other than root of course) full permissions on files that usera wants to share with userb (0770). How else can usera do this if not via usera's group permissions?
At the same time, usera can limit what userb has access to. userb cannot access files that are user and group owned by usera but where usera does not give any permissions at all to members of group usera (0700) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Peter Farrow wrote:
"This allows usera to give userb but no others (other than root of course) full permissions on files that usera wants to share with userb (0770). How else can usera do this if not via usera's group permissions"
they cant if they are each in non joined groups, which is why 0770 is the same as 0700
LOL. I cannot believe that the point was that because new users would be created with their own uid and gid and their home directory ownership set to the same makes a system more sloppy security wise.
Other than this facilitating the future use/need for usera to allow only select users to access some of usera's files, it makes no difference to the 'security sloppiness' of the system.
As you have pointed out it restricts the security granularity of the system, which in turn will lead to other "work arounds" to achieve better granlarity and those work arounds will ultimately lead to sloppiness, making Johns point very valid indeed.
I am glad you found it funny, its always best to keep a light hearted approach and standback and laugh at yourself from time to time, it took you long enough but you got there in the end, and not through any lack of effort on your part either ;-)
well done
P.
Feizhou wrote:
Peter Farrow wrote:
"This allows usera to give userb but no others (other than root of course) full permissions on files that usera wants to share with userb (0770). How else can usera do this if not via usera's group permissions"
they cant if they are each in non joined groups, which is why 0770 is the same as 0700
LOL. I cannot believe that the point was that because new users would be created with their own uid and gid and their home directory ownership set to the same makes a system more sloppy security wise.
Other than this facilitating the future use/need for usera to allow only select users to access some of usera's files, it makes no difference to the 'security sloppiness' of the system. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Peter Farrow wrote:
As you have pointed out it restricts the security granularity of the system, which in turn will lead to other "work arounds" to achieve better granlarity and those work arounds will ultimately lead to sloppiness, making Johns point very valid indeed.
Er...you are going to have to prove the sloppiness part. I, for one, cannot believe an issue was made out of an non-issue.
Each user having their own group ADDS to the security granularity. it does not restrict it.
What is really needed is the ability to limit access to a file on a per user account basis (acls), not by locking down via a group permission. John is creating an issue out of a non-issue.
yeah maybe..... but I think we've all discussed it all enough and maybe all thought about each others input
I know I have....
I still disable it though 'cause its a real pain....
:-)
P.
Feizhou wrote:
Peter Farrow wrote:
As you have pointed out it restricts the security granularity of the system, which in turn will lead to other "work arounds" to achieve better granlarity and those work arounds will ultimately lead to sloppiness, making Johns point very valid indeed.
Er...you are going to have to prove the sloppiness part. I, for one, cannot believe an issue was made out of an non-issue.
Each user having their own group ADDS to the security granularity. it does not restrict it.
What is really needed is the ability to limit access to a file on a per user account basis (acls), not by locking down via a group permission. John is creating an issue out of a non-issue. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Well apart from the furore that my comments generated (which I did put in a rant and apologise for!), these came from people who already are if not sysadmins, well capable of being so.
I understand that by adding someone to your group, they can access your data. All of it. So you have an all or nothing scenario. And you can access someone else's data in the same manner.
But the original idea behind groups as far as I understand it was that they could define a project. The way RH have implemented it, all projects have one person and projects = persons. The way Debian have implemented it, all users are in the same project = there is only one project.
The issue really of course is that you (ordinary hardworking(?) users) can't grant other people access to your data at all. You have to get the sysadmin to do it for you. So in a busy environment, sysadmins are likely to welcome such trivial requests with the open arms of prevarication. Sometimes boxes of chocolates or bunches of flowers may make this a rather quicker procedure - or just being nice can work wonders I believe.
The other way is to use POSIX ACLs - which are a great improvement because they give the user the control. But again these only define a user, groups or other - to define access to a group of people still requires someone to define the group. Back to charming the sysadmin.
Still it makes for an interesting discussion. :-)))
Pip pip
John
John Logsdon "Try to make things as simple Quantex Research Ltd, Manchester UK as possible but not simpler" j.logsdon@quantex-research.com a.einstein@relativity.org +44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
On Tue, 24 May 2005, Peter Farrow wrote:
As you have pointed out it restricts the security granularity of the system, which in turn will lead to other "work arounds" to achieve better granlarity and those work arounds will ultimately lead to sloppiness, making Johns point very valid indeed.
I am glad you found it funny, its always best to keep a light hearted approach and standback and laugh at yourself from time to time, it took you long enough but you got there in the end, and not through any lack of effort on your part either ;-)
well done
P.
Feizhou wrote:
Peter Farrow wrote:
"This allows usera to give userb but no others (other than root of course) full permissions on files that usera wants to share with userb (0770). How else can usera do this if not via usera's group permissions"
they cant if they are each in non joined groups, which is why 0770 is the same as 0700
LOL. I cannot believe that the point was that because new users would be created with their own uid and gid and their home directory ownership set to the same makes a system more sloppy security wise.
Other than this facilitating the future use/need for usera to allow only select users to access some of usera's files, it makes no difference to the 'security sloppiness' of the system. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
But the original idea behind groups as far as I understand it was that they could define a project. The way RH have implemented it, all projects have one person and projects = persons. The way Debian have implemented it, all users are in the same project = there is only one project.
The issue really of course is that you (ordinary hardworking(?) users) can't grant other people access to your data at all. You have to get the sysadmin to do it for you. So in a busy environment, sysadmins are likely to welcome such trivial requests with the open arms of prevarication. Sometimes boxes of chocolates or bunches of flowers may make this a rather quicker procedure - or just being nice can work wonders I believe.
The other way is to use POSIX ACLs - which are a great improvement because they give the user the control. But again these only define a user, groups or other - to define access to a group of people still requires someone to define the group. Back to charming the sysadmin.
Either way, for usera to grant access for certain users to usera's files via group permissions requires sysadmin whether Debian or RH.
Neither is sloppy. You may feel that RH's creates more clutter compared to Debian's all new users belong to one group but it does not create sloppy security. The sysadmin can still create either scenario in either distro but both will still need per user groups to allow user to limit access to certain other users only via group permissions.
On Tue, 2005-05-24 at 09:25, Peter Farrow wrote:
This line " It makes 0700 the same as 0770. "
in the context of one group per user makes perfect sense to me......
What John is getting at is that if one user is assigned their own individual group, then the concept of groups for security granularity is negated which essentially removes the middle part of the unix permissions syntax as the group and user are one and the same, so 0700 is 0770, and in this instance your comment "0700 is and will always be different from 0770" does not apply.... you are right in that 0700 is different to 0770 but the security upshot is the same if each user has their own unique group and in that scenario there is no functional difference between 0700 and 0770.
This is the essence of John's statement which I think you may have missed....
But everyone seems to be missing the real point, which is that if everyone is in a unique group, you can make everything owned by the user also group accessible by default without changing anything. Then when you do want someone to have access, all you have to do is add them to your group. In the pre-RedHat world you also had to go change the group and modes of all your files and change your umask after you realized that sharing is useful. And, of course if you restored anything from backups, it would come back wrong. None of this changes what you can do with other groups.
On May 24, 2005, at 4:04 AM, Peter Farrow wrote:
Maybe so... and if it works for you then use it, but sometimes when people say "but we needed this or we needed that", they haven't allways sat down and thought "why do we need it" or "do we really 'need' this ?"
Even having worked on government classified networks I have *never* seen an instance where the standard access controls offered by Linux/Unix didn't do what was required.
Often DAC/MAC setups leads to inferior security because they can get very complex to setup, and the term "can't see the wood for the trees" springs to mind.
As is most often the case the best security is the simplest, and DAC/MAC bloat doesn't help in any way.
I'm in agreement with you here. Nothing good can be had by throwing additional code at an already complex problem. I understand the need for MAC-type granularity, but SELinux is a bolt-on "solution" that causes as many problems as it solves. The answer lies in simplicity. If the solution cannot be found within the current design, then the current design is broken. Folks should not be afraid to change the UNIX permissions paradigm just because it's been the status quo for decades.
Funny anecdote:
I was giving a lightning talk at a Linux Security mini-conference in PA a couple months back. Marcus Ranum (of Nessus fame) was also speaking there. The overwhelming majority of speakers and attendees were pro-SELinux, as there was a lot of overflow from the DC SELinux conference the week before. Marcus is a very agnostic fellow who will tell you that all operating systems suck at one thing or another. It was funny catching glances of him shaking his head and grimacing as folks extolled the virtues of SELinux on Linux PDA's. :)
-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
"....as folks extolled the virtues of SELinux on Linux PDA's...."
Now that is funny.... :-)
Jason Dixon wrote:
On May 24, 2005, at 4:04 AM, Peter Farrow wrote:
Maybe so... and if it works for you then use it, but sometimes when people say "but we needed this or we needed that", they haven't allways sat down and thought "why do we need it" or "do we really 'need' this ?"
Even having worked on government classified networks I have *never* seen an instance where the standard access controls offered by Linux/Unix didn't do what was required.
Often DAC/MAC setups leads to inferior security because they can get very complex to setup, and the term "can't see the wood for the trees" springs to mind.
As is most often the case the best security is the simplest, and DAC/MAC bloat doesn't help in any way.
I'm in agreement with you here. Nothing good can be had by throwing additional code at an already complex problem. I understand the need for MAC-type granularity, but SELinux is a bolt-on "solution" that causes as many problems as it solves. The answer lies in simplicity. If the solution cannot be found within the current design, then the current design is broken. Folks should not be afraid to change the UNIX permissions paradigm just because it's been the status quo for decades.
Funny anecdote:
I was giving a lightning talk at a Linux Security mini-conference in PA a couple months back. Marcus Ranum (of Nessus fame) was also speaking there. The overwhelming majority of speakers and attendees were pro-SELinux, as there was a lot of overflow from the DC SELinux conference the week before. Marcus is a very agnostic fellow who will tell you that all operating systems suck at one thing or another. It was funny catching glances of him shaking his head and grimacing as folks extolled the virtues of SELinux on Linux PDA's. :)
-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tuesday 24 May 2005 04:04, Peter Farrow wrote:
Maybe so... and if it works for you then use it, but sometimes when people say "but we needed this or we needed that", they haven't allways sat down and thought "why do we need it" or "do we really 'need' this ?"
When all the buffer overflows and other exploits all go away, then we won't need SELinux and its ilk. SELinux, on a workstation or on a server, is great because it helps thwart the malware that will be written and will become more common as Linux becomes more common. SELinux, properly implemented, can stop a virus, worm, even a trojan that the user accidentally or ignorantly clicked on (or the MUA's authors allowed through due to their bug in their code). Anyone in security knows that layered security is best; from firewalling on inward, multiple layers make machines more secure and less likely to be turned into spamming zombies like so many Windoze machines.
Is it complex? Sure it is, but necessarily so, not arbitrarily. Malware is a complex threat, and requires a complex solution. KISS applies; but the adage 'Make it as simple as possible; but no simpler' is more appropriate.
Even having worked on government classified networks I have *never* seen an instance where the standard access controls offered by Linux/Unix didn't do what was required.
Harumph. Systems without MAC don't get anywhere near a SCIF, and you know it, if you have ever worked in a real SCIF environment. I personally have never worked inside an operating SCIF (thankfully), but I have read a defense contractor's Unclassified procedures manual on dealing with SCI inside the SCIF. And I am thankful that national security is taken that seriously.
With HIPAA implemented, the SCIF concept is going commercial, with one group in particular claiming the only fully operational SCIF outside the government. And if you need SCIF spelled out I know you never worked in one. :-)
Often DAC/MAC setups leads to inferior security because they can get very complex to setup, and the term "can't see the wood for the trees" springs to mind.
Simple is not always better. This is why a properly set up policy should be the default; most users will simply not know how to make it work; in testing it must be made work like the typical user would like.
As is most often the case the best security is the simplest, and DAC/MAC bloat doesn't help in any way.
Best is a matter of opinion; MAC provides guaranteed compartmentalization in those situations where compartmentalization is critical. Like HIPAA. In a HIPAA environment, to fully comply, there can be no root user. That is, even the sysadmin must be restricted; there must be multiple admins and none have or can have unrestricted access.
SELinux finally brings Linux up to the level of mid-80's VAX/VMS security. VMS (OpenVMS, that is) is still more secure than any Unix. But SELinux is a step in the right direction. That's why many SCIF sites specified VAXstations and Macintosh systems (again, I've seen unclassified documents showing equipment lists for a former SCIF site (there were multiple SCIF's on the site); VAXstations and old DEC's dominated, with only unclassified material being stored on AT&T 3B15's and 3B2's.).
But even the common user can reap the benefits of MAC in that it doesn't matter whether the intruder gains root or not; what the intruder can do through its exploited conduit is limited by the MAC system and cannot be overridden. If it's a BIND exploit, for example, the SELinux MAC limits what BIND's named can do regardless of whether it gets root or not.
If some document or requirement or spec says you need it, I would often question the theory behind the spec, and only if a demonstrable need arises (have yet to see that in 20+ years of consulting) then I would do it...
If the current rash of exploits and malware isn't a demonstrable need, I have never seen a demonstrable need. Linux is not immune; there are just not that many 'pathogens' out there yet. When the number of exploits goes up (and it will) SELinux is going to save many people's hides.
Of course I've also been in this game too long as well to "never say never" and there is always a first time.... :-)
Have you done HIPAA yet?
Regardless, SELinux helps or can help users protect their systems from malicious intruders; for this alone it is worthwhile to at least learn it. And it's not going to be learned by a busy admin unless it's forced. An admin who is incapable of learning it shouldn't be an admin; it's not that hard of material. And any workstation connected to the internet will be scanned within half an hour and owned in an hour if protection is not there; firewalls are good outer layers, but host security should never be ignored; SELinux is a great addition to the stable of security tools; but like all other layers in the security toolbox there are annoyances; things like firewalls have their issues too, you know.
Bryan J. Smith wrote:
Unfortunately, Mandatory Access Controls (MACs) are a necessary accountability detail needed in many environments.
<snip>
But we needed MAC. It's a good thing to have in many environments -- especially where accountability is essential.
I concede that SElinux may be useful in some enterprise environments or on systems with shared access. For a typical server install, it's simply in the way because it breaks so many other packages and creates an extra layer of complexity where it's really not necessary. I've always thought it should be turned off by default. People that need MAC will know how to turn it back on and it will spare "the innocents" (grin) from posting a gazillion messages about why their favourite software packages are broken with CentOS/RHEL/etc.
Cheers,
C
Hello,
ERROR: relation "pg_catalog.pg_user" does not exist
This looks like a Postgresql error, perhaps the very cool SeLinux is not the problem. Pg_catalog is an internal Pg system table.
I run Postgresql on several flavours of Linux and FreeBSD.
I feel I get a installation by compiling the software all in /usr/local/pgsql. It's also easier to manage across the various OS's.
As this seems Pg related I recommend the Postgresql user mailing list: www.postgresql.org
Compiling is very simple see: www.oreilly.com/catalog/p*postgresql*/*chapter*/ch02.pdf
Postgresql is a very advanced piece of software with lots of configuration options, I have found study the books and compiling has fast-tracked my understanding of the awesome software.
I hope this helps, just my 2 cents :-)
Cheers, Rudi
Peter Farrow wrote:
Just turn off SELinux, it really is a complete pain.
I've managed to set up Linux and Unix boxes securely for years without all the SE Linux baggage.....
All it does is slow the machine down, and adds "bloat" to the OS...
P.
Matt Arnilo S. Baluyos (Mailing Lists) wrote:
hello everyone,
i'm trying to run a postgresql service on my newly-installed centos4 box. i have been able to recreate my users, set up the permissions, and restore the database dump. also, i can already log-in to my databases.
there is, however, one annoying problem. whenever i type \du (or \d or \l) on the psql prompt, i get the following error:
ERROR: relation "pg_catalog.pg_user" does not exist
after some googling, i'm beginning to suspect that this is a SELinux issue. i then try to disable SELinux on the postgresql daemon by doing:
# setsebool postgresql_disable_trans true
that does not work unfortunately as i'm still stuck with the same error.
while i can definitely just disable SELinux on this box, i would want a more elegant solution that solves this annoying problem. can anyone help me on this?
thanks in advance! matt
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
I'm not sure why the link came through like that, it should be:
www.oreilly.com/catalog/ppostgresql/chapter/ch02.pdf
RS
Hi Matt,
On Tue, May 24, 2005 at 02:53:21PM +0800, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
i'm trying to run a postgresql service on my newly-installed centos4 box. i have been able to recreate my users, set up the permissions, and restore the database dump. also, i can already log-in to my databases.
there is, however, one annoying problem. whenever i type \du (or \d or \l) on the psql prompt, i get the following error:
ERROR: relation "pg_catalog.pg_user" does not exist
Yep, I came across this a couple of months ago - it's an selinux bug on postgres initialisation:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150979
There's an updated policy in that thread that fixes the problem, and it'll be included in the upcoming RHEL4 U1.
Cheers, Gavin
On 5/24/05, Gavin Carr gavin@openfusion.com.au wrote:
Yep, I came across this a couple of months ago - it's an selinux bug on postgres initialisation:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150979
There's an updated policy in that thread that fixes the problem, and it'll be included in the upcoming RHEL4 U1.
thanks to everyone who replied particulary to gavin, the information above solved my problem.
i downloaded the selinux-policy-targeted and policycoreutils RPMs from ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u1/ and did an rpm -Uvh on those packages. everything went fine after that.
p.s.: with selinux still enabled, i had an error starting apache afterwards. it was complaining about "bad user name apache" but i had it fixed by running "/sbin/fixfiles restore"
matt
Matt Arnilo S. Baluyos (Mailing Lists) wrote:
while i can definitely just disable SELinux on this box, i would want a more elegant solution that solves this annoying problem. can anyone help me on this?
There's several bug report's on Red Hat's Bugzilla about PostgreSQL and SELinux. You might want to check them out. For starters, there's annoying bug that you must turn off SELinux (or set it to permissive mode) when you start PostgreSQL service for the very first time so that everything initializes correctly. After that you can put it into enforcing mode again, and it will work OK. If you haven't done that, you might want to reinitialize your PostgreSQL installation from scratch (remove everyting from /var/lib/pgsql/data directory).
Also, if your /tmp is on tmpfs, there are couple more issues to address (if /tmp is simply part of root file system like most people have it, you shouldn't have problems with it).
-
Aleksandar Milivojevic -
Bryan J. Smith -
Chris Mauritz -
Feizhou -
Gavin Carr -
Jason Dixon -
John Logsdon -
Lamar Owen -
Les Mikesell -
Matt Arnilo S. Baluyos (Mailing Lists) -
Peter Farrow -
Rudi Starcevic