Hi,
With the default settings I seem to be able to browse all the schools mapped drives (hidden) the "C Drive" (hidden and restricted) and also browse folders that are hidden. Whilst students may not be able to save/delete no school IT dept want the students knowing the full network.
Is there a way that we can restrcit this please?
Many thanks in advance.
No Good For School - Allows access to browse all mapped drives, hidden drives and folders.
-
- KVRer
- 5 posts since 15 Jun, 2011
-
lockon stratos lockon stratos https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=226231
- KVRian
- 510 posts since 18 Feb, 2010 from Pittsburgh area, PA, USA
Lol thats awesome. Oh wait, i'm guessing you're not a student, huh?
Well, you never know where you might find the perfect sample.
Well, you never know where you might find the perfect sample.
External Music Director, WRCT Pittsburgh, 88.3 FM - http://www.wrct.org/
Me on soundcloud - http://soundcloud.com/djdj1
Me on soundcloud - http://soundcloud.com/djdj1
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Which windows version are you on?
How did you restrict access to, for example, the C drive?
How did you restrict access to, for example, the C drive?
-
- KVRAF
- 2285 posts since 20 Dec, 2002 from The Benighted States of Trumpistan
Can other apps access these? If so, the problem is deeper than one app.
I suspect -- well, speculate, really -- that you may have the accessible drives formatted FAT, which has very weak real security features. If so, formatting them as NTFS and using ACLs and all that good stuff should help a lot. It won't stop a dedicated cracker, but it'll deter the incompetent ones.
I suspect -- well, speculate, really -- that you may have the accessible drives formatted FAT, which has very weak real security features. If so, formatting them as NTFS and using ACLs and all that good stuff should help a lot. It won't stop a dedicated cracker, but it'll deter the incompetent ones.
Wait... loot _then_ burn? D'oh!
-
- KVRer
- Topic Starter
- 5 posts since 15 Jun, 2011
Thanks for the replies.
The drives are mapped to a storage array, NTFS is most definetly used, students are restricted to what they can access.
The C drive is retricited and also hidden using group policy.
The mapped drives, ie. \\server\application is mapped to a drive i.e L: but that is also hidden. All the student will only ever see in "my computer" is there home drive "N:" and the Public drive for all students "P:"
This setup is pretty much used by all schools. 99% of applications that try to save use the windows explorer window. so this defaults to there "My documents" (N:)
This app seems to use its own built in save mechanism instead.
It manages to list all the local and mapped drives, but students cannot save as they they have no NTFS permissions to do so (apart from their N drive)
1) Is the source code available? I could then (attempt) to take SAVE to their N drive.
2) Is there anything in the settings that would allow this?
Thanks in advance
The drives are mapped to a storage array, NTFS is most definetly used, students are restricted to what they can access.
The C drive is retricited and also hidden using group policy.
The mapped drives, ie. \\server\application is mapped to a drive i.e L: but that is also hidden. All the student will only ever see in "my computer" is there home drive "N:" and the Public drive for all students "P:"
This setup is pretty much used by all schools. 99% of applications that try to save use the windows explorer window. so this defaults to there "My documents" (N:)
This app seems to use its own built in save mechanism instead.
It manages to list all the local and mapped drives, but students cannot save as they they have no NTFS permissions to do so (apart from their N drive)
1) Is the source code available? I could then (attempt) to take SAVE to their N drive.
2) Is there anything in the settings that would allow this?
Thanks in advance
-
- KVRer
- Topic Starter
- 5 posts since 15 Jun, 2011
Using Group Policy Objects to hide specified drives
http://support.microsoft.com/kb/231289
SCREENSHOT BELOW:
http://www.imageupload.org/getfile.php? ... es.jpg&i=1
http://support.microsoft.com/kb/231289
SCREENSHOT BELOW:
http://www.imageupload.org/getfile.php? ... es.jpg&i=1
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Indeed, for reason of platform independency, which is a good reason when porting Mu apps to any other platforms later. (Linux? Android? Ios? ...)Burgemaster wrote:This app seems to use its own built in save mechanism instead.
Ok, so the issue is a visibility issue of the drives, but permissions are still working so students cannot save to the eg C drive, in such case they get an error. Is that correct?It manages to list all the local and mapped drives, but students cannot save as they they have no NTFS permissions to do so (apart from their N drive)
1) No.1) Is the source code available? I could then (attempt) to take SAVE to their N drive.
2) Is there anything in the settings that would allow this?
2) Not atm.
Just thinking loud: i think permissions should be handled by the OS otherwise this would be a serious security hole!
I also wonder how other apps react. Ok you get a 'standard' Windows file selector which defaults to my documents, but can you browse around and see the C drive then?
-
- KVRer
- Topic Starter
- 5 posts since 15 Jun, 2011
Ok, so the issue is a visibility issue of the drives, but permissions are still working so students cannot save to the eg C drive, in such case they get an error. Is that correct?
Correct, they cannot save. Drive Permissions are still restricting access, but understandably I would not want them to browse through the C drive, browse through the application share, or look at the names of files that are in the cached copy of a teachers "document and settings" who may have logged in before them.
I also wonder how other apps react. Ok you get a 'standard' Windows file selector which defaults to my documents, but can you browse around and see the C drive then?
Any exe that uses the windows explorer to save comply to the OS policies and they can never navigate, browse, create shortcuts to, see any files from any of the restricted drives. Applications running/installed will all have access to the C drive as they running with local permissions. Which I guess is why they are being shown.
Thank you so much for the time replying. I guess it would be out of the question maybe requesting an additional "setting.txt" that sets the default drive to save to ( In our case N: Drive)
Correct, they cannot save. Drive Permissions are still restricting access, but understandably I would not want them to browse through the C drive, browse through the application share, or look at the names of files that are in the cached copy of a teachers "document and settings" who may have logged in before them.
I also wonder how other apps react. Ok you get a 'standard' Windows file selector which defaults to my documents, but can you browse around and see the C drive then?
Any exe that uses the windows explorer to save comply to the OS policies and they can never navigate, browse, create shortcuts to, see any files from any of the restricted drives. Applications running/installed will all have access to the C drive as they running with local permissions. Which I guess is why they are being shown.
Thank you so much for the time replying. I guess it would be out of the question maybe requesting an additional "setting.txt" that sets the default drive to save to ( In our case N: Drive)
-
- KVRAF
- 9091 posts since 28 May, 2005 from Netherneverlands
I think you are using a policy (or lets say Reg-Entry) that can only restrict the explorer.exe and all other programs that uses open/close dialogs from the explorer.exe
If you are running an programs that are not using explorer.exe to browse, like Total Commander, or just use the command prompt then everything is accessable.
It's only depending on the explorer.exe like a lot of other policies do aswell.
So, you can't accomplish your task only by hidding the driveletters.
The user needs to read the files from C: so there is always a way to access the drive. otherwise he wouldn'nt be able to start his environment or even start a program.
You might want to have a look if certain software restriction policy rules could be used here.
If you are running an programs that are not using explorer.exe to browse, like Total Commander, or just use the command prompt then everything is accessable.
It's only depending on the explorer.exe like a lot of other policies do aswell.
So, you can't accomplish your task only by hidding the driveletters.
The user needs to read the files from C: so there is always a way to access the drive. otherwise he wouldn'nt be able to start his environment or even start a program.
You might want to have a look if certain software restriction policy rules could be used here.
-
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
I wonder what's to stop an enterprising youth editing a file and saving it to "shell.bat" then running it and getting command line access? If you're not setting up your security policies more carefully, you're really can't rely on each application being coded to help you.
You can set up security so that User A has no access to documents and settings for any other user. If you're finding they can, you need to review your security policies because you have huge holes.
You can set up security so that User A has no access to documents and settings for any other user. If you're finding they can, you need to review your security policies because you have huge holes.
-
- KVRer
- Topic Starter
- 5 posts since 15 Jun, 2011
You can set up security so that User A has no access to documents and settings for any other user. If you're finding they can, you need to review your security policies because you have huge holes.
You are correct students cannot access inside user B's D&S folder. BUT this application DOES allow the browsing of "folder names" within the cached D&S store. I guess it is running as local system process and using that permission to display the information.
You are correct students cannot access inside user B's D&S folder. BUT this application DOES allow the browsing of "folder names" within the cached D&S store. I guess it is running as local system process and using that permission to display the information.
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
MuLab does nothing special when listing the files and folders.
It's using the standard FindFirstFile and FindNextFile functions, cfr http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Everybody who can make little Windows apps, even simple ones, can make an app that uses these functions to list the content of the file system.
If Windows returns these 'secured' files and folders when calling these functions from a user account that should not see these files and folders, then the security problem is in Windows. Or in the security setup, i'm not a practical expert on that, but that's no issue for the logic.
It's using the standard FindFirstFile and FindNextFile functions, cfr http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Everybody who can make little Windows apps, even simple ones, can make an app that uses these functions to list the content of the file system.
If Windows returns these 'secured' files and folders when calling these functions from a user account that should not see these files and folders, then the security problem is in Windows. Or in the security setup, i'm not a practical expert on that, but that's no issue for the logic.