restricting users file access

[larry308]

I have written an application in C which reads and writes several .txt files in several directories. We need to allow users to run the program but not to read and write the files using Notepad or other editors. The program is written using National Instruments LabWindows/CVI and runs on Windows 2000 and XP. How can I setup file and user permissions to accomplish this?

 

[manvid]

JUs try dis 1 out...
in the properties of the text file,

choose opens with field,

put ur program in the list by browsing it and dont forget
to tick the "always use the selected program to open the file"
maybbe dis shud work..
-vs

 

[jbpelletier]

just a guess...

maybe u could block all user right... and only gave em (by the appz) when u have to read or write then set it back to no rights... this way the file should be avaible "only" by your appz for a very short period of time... like 0-2 seconde... but this aint really "hack proof"

jb

 

[larry308]

Thanks for the advice but I still haven't gotten very far. I tried manvid's advice but even when I checked the "always use ..." box the system still allowed the user to open the file by dragging it to the Notepad icon. Also I got the same advice that jbpelletier gave from some friends I used to work with. I don't know how to change the permissions on a file through a program and my friends couldn't tell me. Thanks again.

 

[Salem]

Two possible solutions

Make the files owned by another user, where only that program has the privileges to access files of that user.
How you would do this in a windows environment I don't know, though I have some idea of how to do it in Linux say.

Encrypt the files in some way, so that even if they read the files, the contents won't make any sense. This is the easier and more portable solution.
How strongly you want to encrypt them depends on who you're trying to keep out - the casual snoop, or the determined cracker.

 

[lionelhill]

Encrypting is definitely the way forwards. The problem is that when your program does its stuff, it does so on behalf of the user. From the OS point of view, it IS the user.
Another way to look at it: your program has no special rights to this file independant of the user. Therefore anything you do that stops the user from accessing these files with notepad will also stop then accessing it with any other program including yours.
Does this make sense?

If you DON'T want to encrypt because you need to be able to read the files as text files, then I suggest you calculate a checksum on the relevant part of the text file, and add this as a number at the end. This way the file will still be text, and although a user can look at it, and even change it, your program will be aware that the file has been tampered with. You of course can make whatever changes you want, because you have access to the checksum function and can re-enter the correct checksum when you're done.

If you DO feel OK about encryption, it really doesn't have to be heavy (in most applications). If the aim is to stop the user from messing up something they don't understand, rather than prevent major fraud, then simply xoring each byte with a funny-looking constant will deter 99.9% of users. For more security set the random number seed and then xor each byte with a random number.
Now I'm going to be pilloried by the proper encryption people who will be horrified...

 

[larry308]

Thanks guys. The things lionelhill describes about permissions, etc., exactly match up with my conclusions after having played around with the system some. I've talked with my manager about encryption and it looks like that's the way we will go. I'm still not sure how much security he wants though. We'll have to talk some more. Thanks again.

 

[butthead]

I probably just reinvented the wheel but you are welcome to it.

key is just about any string.

// This function does the actual encryption and decryption.
int Encrypt (char *string, char *Key, int mode)
{
    // This algorithm stays within the keyboard character
    // environment.
    
        char *s  = new char[1000];
        int x;
        int y;
        int z;
        int len_string;
        int char_value;

        if (mode == ENCRYPT)
        {
            len_string = strlen (string);

            for (x = 0; x < len_string; x++)
            {
                if (string [x] == 0x9)
                    s [x] = 0x9;

                else
                {
                    z = (int) string [x] + ((int) Key [keycount] - 32);
                    if (z <= 126)
                        s [x] = (char) z;
                    else
                    {
                        z = z - 95;
                        s [x] = (char) (z);
                    }

                    keycount++;
                    if (keycount == key_length)
                        keycount = 0;
                }
            }
            s [x] = NULL;
            strcpy (string, s);
        }

        else if (mode == DECRYPT)
        {
            len_string = strlen (string);

            for (x = 0; x < len_string; x++)
            {
                if (string [x] == 0x9)
                    s [x] = 0x9;

                else
                {
                    z = (int) string [x] - ((int) Key [keycount] - 32);
                    if (z >= 32)
                        s [x] = (char) z;
                    else
                    {
                        z = z + 95;
                        s [x] = (char) z;
                    }

                    keycount++;
                    if (keycount == key_length)
                        keycount = 0;
                }
            }
            s [x] = NULL;
            strcpy (string, s);
        }

        delete s;

        return 0;
    }

and as lionehill says let the pillorie begin.

tomcruz.net

tomcruz.net

 

[dlkfjdlkfjdlfkd]

No offense, but you'll want to use something else unless you're satisfied with the cryptographic strength of rot13.

 

[Salem]

Since we don't yet know what level of security is required, then it's hard say whether that's good enough - its good enough for the casual non-technical snoop.

I was going to comment on the use of C++ on the C board, and the buffer overflow which the unnecessary memory allocation introduces.
Simply doing

string [x] = (char) z;

makes the whole need for temporary storage disappear.

I would also suggest that there are other characters other than '\t' which need to be protected to maintain a reasonable text file - like newlines for instance.

 

[lionelhill]

I honestly feel if you are going to encrypt the thing, then there's not much point in treating the result as a text file.

 

[butthead]

dfV^[$x:b\[e15H|P_!D]FyHiG*G,w%*&S2ub)Y@70h+q
?X]zWx*p!@%vd#v(W2@r93!7?]f'( <4VEYo|P%nFsJjTIC2h


decipher this using your rot13.
No offense taken.

tomcruz.net

 

[dlkfjdlkfjdlfkd]

Okay...

qsI^[$k\[r15U|C_!Q]SlUvT*T,j%*&F2ho)L@70u+d
?K]mJk*c!@%iq#i(J2@e93!7?]s'( <4IRLb|C%aSfWwGVP2u

I'm afraid I don't see your point.

 

[butthead]

simple can be decieving

I know you dont get the point.

if you could decrypt the message you would understand.

tomcruz.net

 

[dlkfjdlkfjdlfkd]

You asked me to decipher the message using rot13, so I did, but it still doesn't make any sense to me.

 

[butthead]

&quot;No offense, but you'll want to use something else unless you're satisfied with the cryptographic strength of rot13.&quot;

I have seen encryption algorithms that seeminly were simpler than mine and were probably more secure. your casual reveiw is probably not warranted in this case.

I challenge any one here to decrypt this message.

8YNdgU`8?n\<o`sfws`M[gGdx+;}vU>uKO)F~*qTUqMj>bI~n5YkPQGeq:ao%_HA0Q@s\DS9[DeJiX%`a1'L*l&HnVM~%08(d;?0ZXldt(-E[e,(?3,W75?>*,'7uK-ZBSsTk_&quot;H&quot;{X-fo>]X<nY


tomcruz.net

 

[lionelhill]

Listen to Salem! There is no point in getting into a fight about whether Butthead's encryption is &quot;good enough&quot;. If Butthead was encoding secrets worth a million dollars to me, I'd sit down and have a go at it, and (I hope you won't be anoyed with me Butthead) I flatter myself that given enough encoded text I'd probably manage. But the point is I've got better things to do with my time and I there's not much motivation.

Assuming the original application isn't the sort of thing that every would-be hacker would just love to get their hands on, Butthead's solution is probably More than adequate.

In fact, if you hadn't been told that Butthead's long string of funny looking symbols was encoded ascii, isn't there a possibility you wouldn't even have thought to decode it - it could just as well be a binary file full of floating point numbers, couldn't it (OK, bad example. In this instance I reckon I'd spot a floating point, but you know what I mean)

(As a matter of interest, since Butthead hasn't actually specified whether in this case his text is significantly longer than his key, it isn't clear that it theoretically is soluble)

Li (who knows nothing about crypto and doesn't particularly want to...)

 

[dlkfjdlkfjdlfkd]

I'll admit that my earlier comments did constitute a &quot;casual review&quot; and I retract my statements comparing rot13 to butthead's algorithm. I glanced over the code, without taking note that a key was being used and thought that it amounted to simple letter substitution.

My apologies to butthead.

I agree with lionhill's comments that the specification isn't clear enough to determine whether or not butthead's algorithm is sufficient for the OP's purposes. However, if an &quot;uncrackable&quot; solution is required, then one would be wise to go with one of the &quot;proven&quot; algorithms (i.e. one that has been subjected to extensive peer review and has survived the review without being cracked).

 

[butthead]

since the advent of faster and faster computers and the recent breaking of a 128 bit encryption in europe that demonstrates that even that much security is not absolute. I
am just merely stating the fact that you can rely upon emcryption to much. If the above algorithm is protection against 99.9 percent of potential attempts to crack the information that probably is sufficient. the other small portion of the community can not be defended against in any case. They will get your stuff no matter what you do to the information. Ultimately your information is only as secure as the door behind which it is locked, and the people that you entrust with the information. these are the common avenues of information theft and the information that larry308 is generating could probably be reasonally secure with even rot13. I do not imply that the encrytion code above is anything but an exercise that kept the boredom away one last winter night. I do like the discusion and salems thoughts remind me that I left things unfinished.

thanks dlkfjdlkfjdlfkd , Salem ,lionelhill , and most of
all larry308 , for the topic

tomcruz.net