You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(6) |
Jun
(3) |
Jul
(15) |
Aug
(8) |
Sep
(4) |
Oct
|
Nov
(3) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(8) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(19) |
2007 |
Jan
(7) |
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Patrick F. <pf...@fe...> - 2005-06-08 05:23:46
|
I'm running a custom compiled 2.6.11 gentoo patched r9 kernel. i've enable= d CONFIG_SECURITY and CONFIG_SECURITY_CAPABILITIES and am trying to run t= he trustees module. i've done the following steps in this order (and nothing else from the read= me). 1. compiled the kernel with the above options 2. rebooted to that kernel 3. modprobe trustees (trustees-3.0pre3 -- or pre2 doesn't matter) i get =20 FATAL: Error inserting trustees (/lib/modules/2.6.11-gentoo-r9/extra/truste= es.ko): Invalid argument on the screen and Trustees: Could not register security component in the kernel dmesg log what am i doing wrong? pat |
From: Nima T. <ni...@jc...> - 2005-05-06 09:20:40
|
Here's how check-trustees acts now, I've added a '-v' so that it shows how it calculates what it calculates, as wrong as that may be :). check-trustees -vp /data/imp/drafting/standards/archive/ Verifying...................................................................done ***** PARENT ***** o *:CRWEBX o +imp:REB ***** SELF ***** o *:CRWEBX o +impdraft:REB o +impdes:REB o +impdraftadmin:RWEBX ***** CALCULATION ***** o Reading PARENT * Acting on `+imp' * pFlags: ['R', 'E', 'B'] * mFlags: [] * Selecting ALLOW List o CREATING +imp with R o ADDING E to +imp o ADDING B to +imp * New List: {'+imp': 'REB'} o Reading SELF Wildcard CLEAR * On : +imp * REMOVING R from +imp * New List: {'+imp': 'EB'} * REMOVING E from +imp * New List: {'+imp': 'B'} * REMOVING B from +imp * New List: {'+imp': ''} * DELETING B from +imp * New List: {} o Reading SELF * Acting on `+impdraft' * pFlags: ['R', 'E', 'B'] * mFlags: [] * Selecting ALLOW List o CREATING +impdraft with R o ADDING E to +impdraft o ADDING B to +impdraft * New List: {'+impdraft': 'REB'} o Reading SELF * Acting on `+impdes' * pFlags: ['R', 'E', 'B'] * mFlags: [] * Selecting ALLOW List o CREATING +impdes with R o ADDING E to +impdes o ADDING B to +impdes * New List: {'+impdraft': 'REB', '+impdes': 'REB'} o Reading SELF * Acting on `+impdraftadmin' * pFlags: ['R', 'W', 'E', 'B', 'X'] * mFlags: [] * Selecting ALLOW List o CREATING +impdraftadmin with R o ADDING W to +impdraftadmin o ADDING E to +impdraftadmin o ADDING B to +impdraftadmin o ADDING X to +impdraftadmin * New List: {'+impdraft': 'REB', '+impdes': 'REB', '+impdraftadmin': 'RWEBX'} COMPUTED ALLOW:{'+impdraft': 'REB', '+impdes': 'REB', '+impdraftadmin': 'RWEBX'} COMPUTED DENY: {} Summary for /data/imp/drafting/standards/archive o user `root' has Full Access GRANTED o group impdraft has read-only access (REB) ALLOWED o group impdes has read-only access (REB) ALLOWED o group impdraftadmin has full access (RWEBX) ALLOWED x everyone else has Full Access DENIED Trustees Nodes Requested:130 Trustees Nodes Required :135 No errors in configuration file. No warnings in configuration file. |
From: Nima T. <ni...@jc...> - 2005-05-06 04:58:39
|
Hi Andrew, everyone, Each conclusion I get to seems to create a dozen more questions. It's easy enough to get trustees to do exactly what you want, but trying to get the exact algorithm is proving to be a little more fat that I thought at first. 1. Does trustees read the file, then sort it? eg. Is the file read... [/dev/sda9]/pcp/design/animation/3dm [/dev/sda9]/pcp/design/ [/dev/sda9]/pcp/ [/dev/sda9]/pcp/design/animation/ ...and then sorted into the following: [/dev/sda9]/pcp/ [/dev/sda9]/pcp/design/ [/dev/sda9]/pcp/design/animation/ [/dev/sda9]/pcp/design/animation/3dm ...and then parsed? 2. The information I currently have on how trustees works suggests that at a certain point in calculating the resulting ACLs for a given directory: A. the permissions for '/' are ORed with the default permissions B. the explicite permissions for the directory in question is then applied to A. Is that really true? For example, if we define: [/dev/sda9]/pcp/ [/dev/sda9]/pcp/design/ [/dev/sda9]/pcp/design/animation/ [/dev/sda9]/pcp/design/animation/3dm ...to calculate the permissions for the last line, are the other 3 lines completely reduntant? Or does each directory inherit everything inheritable from its parent (non-oneLevel ACLs), and then apply it's own on top of that? 3. <user>:DU... what does that mean exactly? - U in the allow list ...if not explicitely Denied, check Unix for grant, if not, then proceed to Allow list. - CU ...just ignore Unix permissions - DU ...does that mean something like... 1. Check the Unix Permissions for _deny_, if not denied, continue.. 2. Check the Trustees Deny list, if not denied continue... 3. Check the Trustees Allow list... 4. etc - If so, is the above the correct order? 4. Are the token-pairs on every line read in order? is there any exceptions? eg. [/dev/sda9]/pcp:*:CU:+isg:RXWEB:+imp:DWX:*:CRXWEB -1-- -3------ -2-------- -4------ Apply token-pair 1, then 4, then 2, then 3? What is the rule? I'm sure at least someone wants to shoot me now. Nima |
From: Nima T. <ni...@jc...> - 2005-05-04 08:09:57
|
Hi all, Hi Andrew I've completed *cough* the code to parse the trustees config file, when by *cough*, I naturally mean I have code that executes... on my machine. :) Here is an example of it's output... samson:~# check-trustees -p /data/hst/drafting/jobs/ Verifying...................................................................done Trustees Nodes Requested:126 Trustees Nodes Required :131 No errors in configuration file. No warnings in configuration file. Summary for /data/hst/drafting/jobs o User `root' has Full Access GRANTED o Group isg has Full Access GRANTED o User peter has Full Access GRANTED o Group hstdraft has Full Access GRANTED o User god has Full Access GRANTED o Group hst has Full Access GRANTED o Group staff has Read-Only Access GRANTED o Group draftdata has Full Access GRANTED x Everyone but User peter has Full Access DENIED x Everyone else has Full Access DENIED It's is way from being complete; a couple of problems I know about at the moment are: - It does not treat "O" differently to non-"O" acls. - It speaks bad english. - It does not currently cater for many things, but at least at this point, it is able to... just needs some more work. ...there is more, I am sure. The main reason I'm writing it is to: 1. If it works correctly, I can be confident my man pages are complete. 2. For an accurate (not-yet) english translation of the config file. 3. To simplify the task of writing a reply email to managers with questions such as "Who has access to this directory?" 4. More precise errors/warnings 5. In future - the ability to run say... check-trustees --summary-on +managers ...and get the summary on all paths that this user/group has been explicitely defined for. Anyway, is anyone intrested in joining in? Nima |
From: Neateye <nit...@ao...> - 2005-05-02 22:00:36
|
Call out Gouranga be happy!!! Gouranga Gouranga Gouranga .... That which brings the highest happiness!! |
From: Andrew R. <ae...@ks...> - 2005-05-02 03:58:07
|
Nima Talebi wrote: > I'm writing a small python script to check the trustees configuration > file, make sure that every user and group exists, and also warn on any > directory for which a rule has been defined, but the path does not > actually exist. I think currently settrustees only warns on groups or > users not existing, and not paths. I guess the best way would be that > the settrustees binary itself would do this, and not a separate script. > What are your thoughts? Yes, settrustees should make it a warning. Although it should proceed if the paths do not exist. I can think of times where you'd want to set trustees on files that do not yet exist, but definitely a warning. I have also considered rewriting the settrustees script in python or perl. Writing C programs to do parsing of config files seems to be more trouble than it's worth. I will submit a bug about this right now. Give me a private mail sometime with a desired name/password. I'll set you up a subversion account, it only takes a second. Thanks, Andy -- Andrew Ruder <ae...@ks...> http://www.aeruder.net |
From: Nima T. <ni...@jc...> - 2005-05-02 03:47:54
|
Hi Andy, Andrew Ruder wrote: > Nima Talebi wrote: > >> Hi Andy/Everyone >> >> Since the SMP bug was fixed, trustees has been running on one of our >> main file servers here with no problem at all. What I want to >> confirm/ask in this post is only wrt to documentation. > > > Yea, I'm fully to the point that if I did have an OOPS on my machine, > I'd be reluctant to blame trustees for it. I had a sneaking suspicion > for quite some time that my problems were due to a trustees issue. > >> Trustees does not cater for setgid-bit and sticky-bit, and hence even >> a *:CU does not clear those settings. I just want to confirm that this >> is indeed the intentional. To me it makes sense for it to be, although >> at first I didn't even look for it and wasted alot of time trying to >> figure it out. > > > I have submitted a bug to the bug tracker on sourceforge to clearly > document what is happening in this case. I'm in the midst of finals > week and I just landed an internship, so I'm busy busy busy, but it's > less likely I'll forget about it if its in the tracker. Excellent, and I personally think the behavior is correct as it is currently, and the only thing required is clear documentation. > > I think I will also go through and add all the other bug > reports/requests to the bug tracker... > >> If so, I'd like to add it to the still developing man-pages. > > > You still need to send me those. If you would like, I would be more > than happy to give you access to the subversion repository. I don't > know the first step of writing a man page so it might be interesting to > look at what you have so far. Go ahead and send me an off-list e-mail > if you want me to set you up an account on the subversion machine. I'll do that. The reason I still haven't submitted the man pages is that I have a two good people at informed technology (ftp.wa.au.debian.org) also looking at the man pages, once they are happy with it, and I have fixed it up accordingly, I will send you the 3 pages. I'm trying to make the docs as complete/accurate as possible prior to submitting them. I will also be interested in an account so I'll email you about that too at the same time. I'm writing a small python script to check the trustees configuration file, make sure that every user and group exists, and also warn on any directory for which a rule has been defined, but the path does not actually exist. I think currently settrustees only warns on groups or users not existing, and not paths. I guess the best way would be that the settrustees binary itself would do this, and not a separate script. What are your thoughts? > > And thanks again for all your valuable feedback; I appreciate it. Keep > the bugs and questions coming... it may take me a little while to get to > them, but I'll get to them when I can. > > Thanks again, > > Andy > I've been hunting for trustees on 2.6 for quite a while now, so thankyou for your great work, and it's a pleasure to be of any help at all. Nima |
From: Andrew R. <ae...@ks...> - 2005-04-29 07:37:21
|
Nima Talebi wrote: > Hi Andy/Everyone > > Since the SMP bug was fixed, trustees has been running on one of our > main file servers here with no problem at all. What I want to > confirm/ask in this post is only wrt to documentation. Yea, I'm fully to the point that if I did have an OOPS on my machine, I'd be reluctant to blame trustees for it. I had a sneaking suspicion for quite some time that my problems were due to a trustees issue. > Trustees does not cater for setgid-bit and sticky-bit, and hence even a > *:CU does not clear those settings. I just want to confirm that this is > indeed the intentional. To me it makes sense for it to be, although at > first I didn't even look for it and wasted alot of time trying to figure > it out. I have submitted a bug to the bug tracker on sourceforge to clearly document what is happening in this case. I'm in the midst of finals week and I just landed an internship, so I'm busy busy busy, but it's less likely I'll forget about it if its in the tracker. I think I will also go through and add all the other bug reports/requests to the bug tracker... > If so, I'd like to add it to the still developing man-pages. You still need to send me those. If you would like, I would be more than happy to give you access to the subversion repository. I don't know the first step of writing a man page so it might be interesting to look at what you have so far. Go ahead and send me an off-list e-mail if you want me to set you up an account on the subversion machine. And thanks again for all your valuable feedback; I appreciate it. Keep the bugs and questions coming... it may take me a little while to get to them, but I'll get to them when I can. Thanks again, Andy -- Andrew Ruder <ae...@ks...> http://www.aeruder.net |
From: Andrew R. <ae...@ks...> - 2005-04-28 15:00:28
|
Rob See wrote: > What would the effect of running trustees on an NFS server be ? Would > users on the nfs client end up with the additional permissions granted > by trustees. If the NFS server and client had support for acls, would > the client have access based on the acls even though trustees is running > on the server ? I am entirely unsure how trustees would interact with a NFS server as I don't understand the inner workings of nfsd; however, I am fairly certain it would work since surely the nfs server checks permissions using normal syscalls. One caveat to using trustees is that it only supports UNIX style permissions. The second you load the trustees module, your ACLs will no longer have any effect. And since I'm pretty sure all permission checking is done on the server, you would not be able to use ACLs on the nfs share. Of course, once again, I'm bitten by my lack of experience with NFS. Does nfsd utilize regular POSIX ACLs (i.e. getfacl/setfacl) or does it use some sort of file-based access scheme similar to trustees? I have been meaning to set up a NFS server on my test box and play around with it; maybe I can get to this on the weekend. If you do decide to go ahead and mess with it, please report your findings. I'm a bit interested how it does interact with a shared file system... Thanks, Andy -- Andrew Ruder <ae...@ks...> http://www.aeruder.net |
From: Rob S. <ro...@rs...> - 2005-04-28 12:12:46
|
Hi, What would the effect of running trustees on an NFS server be ? Would users on the nfs client end up with the additional permissions granted by trustees. If the NFS server and client had support for acls, would the client have access based on the acls even though trustees is running on the server ? Thanks, -Rob |
From: Nima T. <ni...@jc...> - 2005-04-28 08:44:42
|
Hi Andy/Everyone Since the SMP bug was fixed, trustees has been running on one of our main file servers here with no problem at all. What I want to confirm/ask in this post is only wrt to documentation. Trustees does not cater for setgid-bit and sticky-bit, and hence even a *:CU does not clear those settings. I just want to confirm that this is indeed the intentional. To me it makes sense for it to be, although at first I didn't even look for it and wasted alot of time trying to figure it out. If so, I'd like to add it to the still developing man-pages. Nima Andrew Ruder wrote: > Rob See wrote: > >> Is this new version kernel version independent ? Is the LSM API >>stable enough to be able to say that assuming no bugs are found Trustees >>3.0 will work for the rest of the 2.6 releases ? > > > As far as I can tell, the LSM API has been fairly stable throughout the > 2.6 kernel as far as trustees is concerned. LSM supplies several hooks, > but trustees is currently only using 3 or 4 of them, so I don't expect > any problems. > > I'm thinking that when I do get around to getting out a trustees 3.0 > final, I will supply patches to several new kernels, but for now it > works very well as an external API. In the series from about 2.6.5 to > 2.6.12-rc1, I haven't had any problems with LSM api instability... > > - Andy > |
From: Andrew R. <ae...@ks...> - 2005-04-19 18:20:45
|
Rob See wrote: > Is this new version kernel version independent ? Is the LSM API > stable enough to be able to say that assuming no bugs are found Trustees > 3.0 will work for the rest of the 2.6 releases ? As far as I can tell, the LSM API has been fairly stable throughout the 2.6 kernel as far as trustees is concerned. LSM supplies several hooks, but trustees is currently only using 3 or 4 of them, so I don't expect any problems. I'm thinking that when I do get around to getting out a trustees 3.0 final, I will supply patches to several new kernels, but for now it works very well as an external API. In the series from about 2.6.5 to 2.6.12-rc1, I haven't had any problems with LSM api instability... - Andy -- Andrew Ruder <ae...@ks...> http://www.aeruder.net |
From: Rob S. <ro...@rs...> - 2005-04-19 17:50:29
|
All, I'm glad to see that trustees has returned to life. I was a big fan of the old incarnation of it. I still haven't found a good replacement (RSBAC being the closest, but overkill and not quite right for what I wanted.) Is this new version kernel version independent ? Is the LSM API stable enough to be able to say that assuming no bugs are found Trustees 3.0 will work for the rest of the 2.6 releases ? Thanks, -Rob |
From: Andrew R. <ae...@ks...> - 2005-04-15 08:45:37
|
Hello all, Hubert Touvet made an excellent spot where permissions were not being applied correctly to the root directory of a share in some cases. For example, if you had [/dev/hda1]/:andy:RWEBX And I (andy) tried to touch /somefilethatdoesntexist, I would be unable to. All the permissions were propogating correctly, they were just not being applied to the root directory on files that did not exist already. Go grab trustees 3.0pre3 at: http://prdownloads.sourceforge.net/trustees/trustees-3.0pre3.tar.bz2?download Cheers, Andy -- Andrew Ruder http://www.aeruder.net |
From: Andrew R. <ae...@ks...> - 2005-04-10 09:51:03
|
Just a test; I repeat, just a test. - Andy -- Andrew Ruder <ae...@ks...> http://www.aeruder.net |
From: Andrew R. <ae...@ks...> - 2005-04-09 07:10:34
|
I just released 3.0pre2 of trustees. It fixes a major problem with memory corruption that could lead to lockups, oops, and other strange problems. There are some other bug fixes as well, so give it a download. - Andy -- Andrew Ruder http://www.aeruder.net |