FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 02-12-2011, 03:19 AM
Les Mikesell
 
Default Strange Kernel for Centos 5.5

On 2/11/11 6:55 PM, Nico Kadel-Garcia wrote:
>
>> you go back to '95 and look at the security/design flaws in shipping
>> Linux products it is not pretty either. Pretty much everything had wide
>> open holes in required network services like bind/sendmail/ftp as well
>> as the kernel itself (wade through the changelogs on any of the programs
>> if you aren't convinced). I do agree that pre XP/SP2 versions of
>> windows were badly broken and still resent the trouble they caused, but
>> it's probably time to forget that.
>
> Not as big, serioiusly. The separation between "userspace" and
> "kernelspace" and "root access" was much better than it has been in
> the Windows world.

So exactly what couldn't you do after exploiting one of the holes in bind or
sendmail or the kernel? It is only recently that bind was moved to a chroot and
sendmail to mostly run as a non-root user.

> Sadly, freenx is abandonware. So is neatx. (I've been working with
> them lately.) The clients and servers from NoMachine are pretty good,
> and play nicely on CentOS. (I'm using them now for personal use, which
> their license allows.) The new NX version 4 alpha release is very,
> very alpha. We'll see how it works out in the long term. I've been
> trying to pay them for licenses, but the licensing model hasn't fitted
> anything I can *explain* to the people who sign checks.

Yes, it's too bad memory wasn't cheap back when X was designed or maybe they
would have done client caching in the first place.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 03:48 AM
Johnny Hughes
 
Default Strange Kernel for Centos 5.5

On 02/11/2011 09:36 PM, Joshua Baker-LePain wrote:
> On Fri, 11 Feb 2011 at 6:38pm, Drew wrote
>
>>> RHEL and CentOS have much, much tighter basic privilege handling. The
>>> complexity of the NTFS ACL structure, for example, is so frequently
>>> mishandled that it's often ignored and simply dealt with as
>>> "Administrator". The result is privilege escalation chaos.
>>
>> And how is the user-group-world permissions system any better?
>>
>> I work daily with both *nix & NTFS ACL's and given the choice I prefer
>> NTFS' for the finer grained control.
>
> Erm, *nix has fully functional ACLs as well. 'man setfacl'
>

In fact, you can do things very easily with *nix acls that are very
difficult in Windows. For example, you can set different 'Default'
permissions (what will be on things created in the directory) than the
permissions that are actually on the directory. You can set different
masks for different groups or users in the same directory, etc.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 05:57 AM
"Joseph L. Casale"
 
Default Strange Kernel for Centos 5.5

>In fact, you can do things very easily with *nix acls that are very
>difficult in Windows. For example, you can set different 'Default'
>permissions (what will be on things created in the directory) than the
>permissions that are actually on the directory. You can set different
>masks for different groups or users in the same directory, etc.

That's not accurate. You can do exactly that very trivially with Container
Inheritance flags only etc...

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 08:52 AM
Johnny Hughes
 
Default Strange Kernel for Centos 5.5

On 02/12/2011 12:57 AM, Joseph L. Casale wrote:
>> In fact, you can do things very easily with *nix acls that are very
>> difficult in Windows. For example, you can set different 'Default'
>> permissions (what will be on things created in the directory) than the
>> permissions that are actually on the directory. You can set different
>> masks for different groups or users in the same directory, etc.
>
> That's not accurate. You can do exactly that very trivially with Container
> Inheritance flags only etc...

It is NOT trivial in Windows to have the permissions on a directory set
so that Bob has rwx permission on the directory, but when new files (or
directories) are created in that directory Bob has r-- permissions on
the files inside the said directory.

You can "assign" different permissions on each file and directory in
Windows by turning off inheritance and making an assignment. You can
not easily make default create permissions be different than the
container the objects are created in.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 09:05 AM
John R Pierce
 
Default Strange Kernel for Centos 5.5

regardless of the OS, any time you start to get tricky with per object
permissions, before long you end up with a complex mess that's a pain in
the butt to keep track of.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 11:50 AM
Nico Kadel-Garcia
 
Default Strange Kernel for Centos 5.5

On Fri, Feb 11, 2011 at 9:38 PM, Drew <drew.kay@gmail.com> wrote:
>> RHEL and CentOS have much, much tighter basic privilege handling. The
>> complexity of the NTFS ACL structure, for example, is so frequently
>> mishandled that it's often ignored and simply dealt with as
>> "Administrator". The result is privilege escalation chaos.
>
> And how is the user-group-world permissions system any better?
>
> I work daily with both *nix & NTFS ACL's and given the choice I prefer
> NTFS' for the finer grained control.
>
> You want to create a folder in which user A & B have access to but
> nobody else? In *nix you create a group that both those users belong
> to and set the folder to use that group's permissions. In NTFS you set
> the ACL's so those two users have (almost) full access to the folder.
> Simple enough.

If you *need* that level, you use NTFSv4 ACL's. But the result is
often that it gets so complex, so fast, that ever figuring out who
ever owned or had access to something in the first place is a
nightmare. It slows filesystems, it complicates backups, and it's
proven itself fairly dangerous because of the tendency to toss in
extraneous access.

> Now let's say we want User A to have read only access to that second
> folder? They're not the owner, and don't belong to the group, so world
> permissions are your only choice. What if this folder is a
> confidential folder containing files the CEO & VP should be able to
> alter but the Admin Assistant needs to be able to pick files from? You
> really don't want a lowly peon down in shipping seeing the
> confidential memo now do you?

Yes, it solves some problems. But the complexity and inconsistencies
get pretty nasty pretty fast, and I've found the results a nightmare
in privilege escalation issues, and the mishandling so very common in
basic system configuration files and common software that it's rarely
worth the difficulty to resolve.

> In NTFS you just add user A to the folder with read only permissions.
>
> Now expand this out to hundreds of folders and watch the *nix groups
> multiply like rabbits.

Only if you're trying for that fine a grain of control. If you need to
handle that fine grained control, it's not a file system issue it's a
procedural one.

> Admittedly a few areas of NTFS ACL's cause some confusion, inheritance
> and precedence rules among them, but if you take the time to read how
> they work and play with it before putting it into production it's
> actually quite easy to work with.
>
> RTFM? :-)

Easy to work with, and way, way, way too common to screw up.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 12:02 PM
Natxo Asenjo
 
Default Strange Kernel for Centos 5.5

On Sat, Feb 12, 2011 at 3:38 AM, Drew <drew.kay@gmail.com> wrote:
>> RHEL and CentOS have much, much tighter basic privilege handling. The
>> complexity of the NTFS ACL structure, for example, is so frequently
>> mishandled that it's often ignored and simply dealt with as
>> "Administrator". The result is privilege escalation chaos.
>
> And how is the user-group-world permissions system any better?
>
> I work daily with both *nix & NTFS ACL's and given the choice I prefer
> NTFS' for the finer grained control.
>
> You want to create a folder in which user A & B have access to but
> nobody else? In *nix you create a group that both those users belong
> to and set the folder to use that group's permissions. In NTFS you set
> the ACL's so those two users have (almost) full access to the folder.
> Simple enough.

in unix you can use acls as well. See getacl/setacl. No sweat.

Anyway, neither in windows nor in unix/linux you want to specify
permissions on a per user level. Always groups. If the user leaves the
company and the permissions are on a per user level you need to start
all over again. If on a per group level, just disable/remove the user
from the group and it keeps working for the rest of members.

Bonus points if you enable your helpdesk group to administer the groups
and the children folders so you no longer have to waste any time with
this boring stuff.

--
natxo
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 12:09 PM
Christopher Chan
 
Default Strange Kernel for Centos 5.5

On Saturday, February 12, 2011 09:02 PM, Natxo Asenjo wrote:
> On Sat, Feb 12, 2011 at 3:38 AM, Drew<drew.kay@gmail.com> wrote:
>>> RHEL and CentOS have much, much tighter basic privilege handling. The
>>> complexity of the NTFS ACL structure, for example, is so frequently
>>> mishandled that it's often ignored and simply dealt with as
>>> "Administrator". The result is privilege escalation chaos.
>>
>> And how is the user-group-world permissions system any better?
>>
>> I work daily with both *nix& NTFS ACL's and given the choice I prefer
>> NTFS' for the finer grained control.
>>
>> You want to create a folder in which user A& B have access to but
>> nobody else? In *nix you create a group that both those users belong
>> to and set the folder to use that group's permissions. In NTFS you set
>> the ACL's so those two users have (almost) full access to the folder.
>> Simple enough.
>
> in unix you can use acls as well. See getacl/setacl. No sweat.
>
> Anyway, neither in windows nor in unix/linux you want to specify
> permissions on a per user level. Always groups. If the user leaves the
> company and the permissions are on a per user level you need to start
> all over again. If on a per group level, just disable/remove the user
> from the group and it keeps working for the rest of members.

And what do you do when you have cases that a user needs access to these
set of files/directories but not all the files/directories the group has
access to?
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 01:16 PM
Tom H
 
Default Strange Kernel for Centos 5.5

On Sat, Feb 12, 2011 at 8:09 AM, Christopher Chan
<christopher.chan@bradbury.edu.hk> wrote:
> On Saturday, February 12, 2011 09:02 PM, Natxo Asenjo wrote:
>>
>> Anyway, neither in windows nor in unix/linux you want to specify
>> permissions on a per user level. Always groups. If the user leaves the
>> company and the permissions are on a per user level you need to start
>> all over again. If on a per group level, just disable/remove the user
>> from the group and it keeps working for the rest of members.
>
> And what do you do when you have cases that a user needs access to these
> set of files/directories but not all the files/directories the group has
> access to?

We create specific groups and netgroups for teams/subteams accessing
specific shares and servers.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-12-2011, 04:14 PM
Les Mikesell
 
Default Strange Kernel for Centos 5.5

On 2/12/11 4:05 AM, John R Pierce wrote:
> regardless of the OS, any time you start to get tricky with per object
> permissions, before long you end up with a complex mess that's a pain in
> the butt to keep track of.

And this is especially true if you don't first map the users to a group role or
job position, then set appropriate permissions for files/directories based on
the roles instead of the individuals that are temporarily involved with them.
You really don't want to maintain systems by searching the entire filesystem for
acls containing a user and changing it to some other user. And generally you'll
want a mail group associated with the role as well. I always liked the way SME
server let you associate users with groups in its web admin interface and then
took care of the details of setting up permission groups and mail groups for
you. Too bad it doesn't do LDAP to make it suitable for places with more than
one server.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 09:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org